So far this is what I understand objects are, I need feedback to know if I'm correct.
A class is made up of member functions. A class also defines types like int does.
An object is defined by that class and then the object calls the member functions within that class (only in the class it was defined by).
Need to know if I'm missing anything or if I'm wrong about something. Thanks
A class is made up of member functions.
Not necessarily, classes can contain data members too.
A class also defines types like int does.
True
Then the object calls the member functions within that class
Once, you go through the concepts of inheritance, you will understand that, an object can call methods of its base classes
Related
I have seen is possible to instantiate an object who implements an interface instead of a class. Iยดd like to know what are the benefits of this.
I attach an example :
Interface just tells the program, that this object it just received has these methods defined. So you can have multiple different classes implement the same interface. And when a method accepts a given interface, then it can accept all the classes that implement the interface.
By instansiating a class into interface, you are saying, that whatever following code does, it cares only about the methods stated in the interface.
If you instansiate into class type, you are saying you want only this spesific type and none else.
I was wondering if SystemVerilog has a generic class handler similar to how Java has an "Object" class or how C has a void*?
If so, what is it called? What I'm trying to do is have a class that when it is instantiated is passed a defined object, however it could be any object. So, I'm hoping that I can have an empty handler to this unknown data class (or generic) and I'm hoping that I don't have to create an empty data class and use one that is already part of the SystemVerilog library.
I should add that I'm not using UVM or any other methodologies, otherwise I would have just started from a uvm_component or uvm_object.
Java's Object class is the root base class of all classes. There is no such root class in SystemVerilog.
The UVM's uvm_object provides the functionality you are looking for and I suggest using it if for nothing else.
I have read how companion and singleton objects can be used to keep static methods, which makes sense. My question is how is this object made or instantiated it? I have read from some sources on how Objects are instances of the class if used as companion objects while others say they are not instances of the class. Then how are the objects existing or being made? Plus the Object would be same class data type I suppose?
My question is how is this object made or instantiated it?
[โฆ]
Then how are the objects existing or being made?
You don't know, shouldn't know, and can't know.
The Scala Language Specification says that they exist. The Scala Language Specification does not say how they are instantiated. Every implementor is free to implement them however they want.
For example, ECMAScript has object literals, so for Scala.js, there is no need for them to be an instance of any class at all. Scala-native is not dependent on any platform, so it can do whatever it wants. Scala-JVM needs to comply with the restrictions of the JVM, where every object needs to be an instance of a class. In Scala-JVM, every singleton object Foo is an instance of a JVM class named Foo$.
Plus the Object would be same class data type I suppose?
The type of a singleton object Foo is the singleton type Foo.type. It's not a class.
I have read from some sources on how Objects are instances of the class if used as companion objects while others say they are not instances of the class.
Instead of reading "some sources", it's much better to just read the source: the Scala Language Specification, specifically section 5.3.2 Case Classes:
A case class definition of ๐[tps](ps1)โฆ(ps๐) with type parameters tps and value parameters ps implies the definition of a companion object, which serves as an extractor object. It has the following shape:
object ๐ {
def apply[tps](ps1)โฆ(ps๐): ๐[tps] = new ๐[Ts](xs1)โฆ(xs๐)
def unapply[tps](๐ฅ: ๐[tps]) =
if (x eq null) scala.None
else scala.Some(๐ฅ.xs11,โฆ,๐ฅ.xs1๐)
}
Each object has its own class, but you can't access the class directly. This class has a constructor without parameters which is called automatically when it's loaded and creates the only instance.
Objects are instances of the class if used as companion objects
Either you misunderstood or you really shouldn't trust these sources. It's possible for a companion object to extend the trait/class it's companion to, but not at all common.
Companion objects are not instances of the class they're companion of, think of them more like a collection of utility methods. If you're familiar with Java - all the method, that you made static in Java (hence they don't belong to a particular instance, but to class in general) would go to Companion object in Scala. Also, companion objects have access to classes private values.
Objects are lazily initialized for you, you don't need to know when and how exactly are they created, just if you call a function from an object - it will be created for you, and there will be only one instance of it.
I am having trouble understanding my professor's lecture notes because my brain seem to treat objects, attributes, variables and class instance as interchangeable. I really appreciate any help in distinguishing these 4 terms. Thank you!
this would be helpful for u Visit https://www.quora.com/What-is-the-difference-between-instance-variable-and-class-variable
Class variables are declared with keyword static and Instance variables are declared without static keyword.
Class variables are common to all instances of a class. These variables are shared between the objects of a class. Instance variables are not shared between the objects of a class. Each instance will have their own copy of instance variables.
As class variables are common to all objects of a class, changes made to these variables through one object will reflect in another. As each object will have its own copy of instance variables, changes made to these variables through one object will not reflect in another object.
Class variables can be accessed using either class name or object reference. Instance variables can be accessed only through object reference.
https://qph.fs.quoracdn.net/main-qimg-c4b92e80a8500c11fe705c1bafc3ed26
You don't mention the programming language at question.
Usually a class is a model or template that declares
how a certain category of objects look like.
You give a class a name and you mention if it inherits
members from another class or not.
You define also the class members.
These can be variables that hold data (object state)
and methods (class defined functions) that define
the object behaviour.
When you instantiate a class using the declared model
, you get an object, that is a concrete class instance.
This is a concrete entity, think of it as a new variable in memory,
whose data type is the class (instead of for example
integer or string data types), whose value is its state
in a defined moment in time (the state being the
combination of all of its data member variables values
at that moment). This object has to have an identity,
because it exists in memory and it is a different entity
from the other objects you can instantiate from this or
any other class. The data member variables hold specific
values for each instance. These are not shared between
instances.
Now the member methods can be shared between instances
because they have no state, so they are equal for every object.
They are called with some arguments
and they do some action that changes the object state, or
is at least tightly related with the concrete object.
But they are common to every object. The methods usually
know what concrete object they act upon by means of a special
name like 'this' or 'self', that references to 'itself'.
Objects are usually assigned to variables upon creation,
storing a reference to its identity that allows the
remaining code to manipulate them.
You use these variables to refer to the concrete object
outside the code of the classes, and use 'this' or 'self'
to refer to it from inside the classes.
Frequently you access object members qualifying with the
object name. Like in 'player.run()', or 'player.total_score'.
That is if player is a variable to which you assigned a
class Player instance. This can look like player = new Player
or player = Player().
Attributes is just another name given to data members.
Sometimes attributes and also methods can be public or private,
meaning code outside the class can use them, or only
the class code can have access.
Sometimes you see data members or attributes referred as
properties. When you access an attribute, you are accessing
a property. In some languages like Python, property can mean
something a little different but close related anyway...
Now also depending on the language things can be like described
(C++, Java) or you can have everything being treated as objects,
including the class definitions (Python).
You should also search the internet or SO about
inheritance, overriding, class diagrams, and other things class
related.
This is all no more than the ability of defining your own data types
beoynd the language builtin types.
You can think of variables as names for boxes (memory containers in a certain address) holding values. But sometimes you want to manipulate
not the values but the addresses themselves. This time you say you have
references (to addresses). Sometimes variables are just names for those
references. References are also known as pointers. But you could do math with pointers (increment, decrement, add a fixed value to...) that you usually don't do with references.
I am having trouble understanding with some of the code snippets about this part of the Java tutorial: http://docs.oracle.com/javase/tutorial/java/IandI/interfaceAsType.html
public Object findLargest(Object object1, Object object2) {
Relatable obj1 = (Relatable)object1;
Relatable obj2 = (Relatable)object2;
if ((obj1).isLargerThan(obj2) > 0)
return object1;
else
return object2;
}
and:
public interface Relatable {
// this (object calling isLargerThan)
// and other must be instances of
// the same class returns 1, 0, -1
// if this is greater than,
// equal to, or less than other
public int isLargerThan(Relatable other);
}
In the first example, why am I downcasting Object types into Relatable types? What happens if the first method doesn't include the first two statements?
Let's say I wrote a Rectangle class that implements the Relatable interface and has the "findLargest" method. If I know that I'm comparing two Rectangle objects, why not just make the first method downcast the objects into Rectangles instead?
You cast the Objects into Relatable types because otherwise you cannot use the methods declared in the Relatable interface. Since Object does not have the isLargerThan method, you would get a compiler error without casting. Honestly, in my opinion the findLargest method as shown here was not very well designed; a better illustration of the purpose of Interfaces would be to ask for Relatable objects as the parameters like so:
public Object findLargest(Relatable object1, Relatable object2) {
//implementation not shown to save space
}
This way, the user must pass Relatable objects, but they can pass any object whose class implements Relatable (such as Rectangle)
"If I know that I'm comparing two Rectangle objects..."True, if you know that you are comparing two Rectangle objects, there is little use for an interface, but the purpose of interfaces is to allow you to create a generic "type" of object that can be used to define common features of several different classes.For example, what if you also had a Circle class and a Square class (both of which implemented Relatable)? In this case, you do not necessarily know the exact type of object you have, but you would know that it is Relatable, so it would be best to cast to type Relatable and use the isLargerThan method in a case like this.
Interfaces define a set of methods which every class which the interface implements has to implement. The downcast is necessary to get access to these methods.
You don't know if you are comparing rectangles with this interface. You could get any Relatble passed. This is one of the cases generics come in handy.
1.In the first example, why am I down casting Object types into Relatable types? What happens if the first method doesn't include the first two statements?
Answer
Every object has some basic functionality and you want a specific object write now. You are down casting your object into a "Relatable" so you can use the "isLargerThan" method(an object wont have it since it has only basic common stuff).
If you didn't down cast, you would not pass compilation.
2.Let's say I wrote a Rectangle class that implements the Relatable interface and has the "findLargest" method. If I know that I'm comparing two Rectangle objects, why not just make the first method downcast the objects into Rectangles instead?
Answer
Since you want to create something generic.
Lets say you have a Student and a Driver. Both of them are People. You can create an interface called IPeople and make both the Student and the driver implement it.
IPeople will have a method called "getAge()" that each of them will implement.
IPeople will have all the functionality that you need for "People". That's how you create cross object functionality under the "same hat".