This question already has answers here:
What is the difference between an Instance and an Object?
(25 answers)
Closed 1 year ago.
I just want to know what is the difference between an object and instance with example.
An object is a software bundle of related state and behavior. A class is a blueprint or prototype from which objects are created. An instance is a single and unique unit of a class.
read more :Class vs Object vs Instance
Often the words instance and object are synonyms. Read more about objects
Some languages (e.g. Smalltalk, Common Lisp, and even MELT) are reifying their classes, by having classes instances of meta-classes. In that case, you might say that these class objects are not instance (but it is a matter of terminology and context).
In other languages (e.g. C++) classes are not objects, e.g. because they make only sense at compile-time.
Some object oriented languages (e.g. JavaScript or Self) don't have classes but prototypes.
As has been already mentioned, a class is a blueprint/recipe for creating objects. Hence,
A class is a blueprint for creating objects of that class.
On the reverse side, an object is an instance of that class.
"Object" is a runtime concept, it exists while running. That is when, for example in Java,
when the program execution reaches a statement where is says
ClassA objA = new ClassA();
it is then that an object of that class is created, or instantiated. In the above code, objA is an instance of ClassA.
Related
I tried to think of a better name for this is but I couldn't.
Also every topic on this involves python and I don't know python
I know that the dafult :meta-class is standar-class
And that standard-object is an instance of the standard-class and that every class is an instance of the standard-class and inherits everything from the standard-object but how is this this possible?
As in how can standard-object be an object and a superclass both at the same time?
How does it work and why?
What I don't understand is how can an instantained class be also a class?
One way to think about it is to forget that bootstrapping is a problem and imagine that the object system is “just so” and then it seems natural that:
everything is an object
every object is an instance of a class
every (standard) class is a subclass of standard-object
a class is an object
every standard class is an object which is an instance of standard-class
standard-class is a standard class which is an object which is an instance of standard-class and a subclass of standard-object which is a class which is an object which is an instance of standard-class
I tried and failed to find a good diagram.
Another way to think about this is about bootstrapping. How can you make the above state come to be?
One way is that you can make an object without its class existing:
Decide on the memory layout of objects
Knowing how to lay out an instance of standard-class in memory, allocate an instance that will become the class standard-class
Initialise that instance with the right things. Set its class to be itself. Don’t set any superclasses yet
Do the same to allocate an instance that will become standard-object (and other parts of the hierarchy, ie class, the class of T, generic-function, method, etc)
The class of all of these objects can be set to standard-class
Connect up the class hierarchy relationships
Create generic functions and methods for allocating instances and compiling generic functions and such
Welcome to your new object system
You could ask yourself the question in reverse: why would a class not be an object, in an object-oriented programming language?
What is a class? It's something that contains information about how to create new objects, things like fields, default values, etc… In OOP, the default tool to store data together is an object. So CL's classes are just objects! And because classes are objects themselves, of course they have a class, STANDARD-CLASS (STANDARD-OBJECT is the direct superclass of a class without any other superclasses… cf. Inheritance structure of metaobject classes).
As an exercise, you can try to create your own (very simple) object system and you may discover very fast that having your classes being objects would make your life way easier. Going from there, there is just the slight problem of bootstrapping. :-)
I'm a new comer to Smalltalk, and learned it in Squeak. But I find many things confusing in Smalltalk. In Squeak, MetaClass and MetaClass class are each other's class mutually. If I want to create the object MetaClass I should send a message new to its class which is MetaClass class. But it must have already existed as an object in the first place to accept the message. So I must create the object MetaClass class first, which can only be done by sending a message new to the object MetaClass which has not been created yet. So it is a chicken-or-the-egg problem.
Of course I can create the objects in Squeak now, because the MetaClass and MetaClass class objects have already been created auto-magically when Squeak is opened. But I don't know how. Maybe they are created somehow rather by sending messages. But then it contradicts Smalltalk's spirits: everything happens by sending messages except a few points (variable declaration, assignments, returns and primitives).
Is there something wrong with the above reasoning? Thanks in advance.
Your question is twofold, lets answer them separately.
How do mutual dependent classes get created?
You are right, Metaclass and Metaclass class are a singularity in the parallel hierarchy of the Smalltalk classes and metaclasses. How are they created?
That depends on the Smalltalk you are using. For GNU Smalltalk I am unsure, but for the descendants of the original Smalltalk-80 (VisualWorks, VA aka VisualAge, SqueakPharo) the are created in a Bootstrap process that creates an initial image.
However, at least for Squeak, this bootstrap happened at least 15 years ago, if not more. Metaclass and its class may even be as old as 30 years.
Long story short, both classes are created outside the typical image processing and linked together manually.
But if the objects are years old, that leads to the question
What happens at Smalltalk’s startup?
Contrary to languages like Ruby or Python, which are object-oriented, too, Smalltalk does not need to create a basic object environment with things like Object on every startup. Why?
When Smalltalk saves and shuts down, it basically takes a snapshot of all its object and saves those live object to a file. When it starts up again, it just has to read the objects from the snapshot and “revive” them.
Hence, for Metaclass and Metaclass class, both objects are read from the snapshot and revived, and from this point on, they are fully functional; they don’t need to be manually created anymore.
The 'automagically created' process actually is called bootstrapping. This is how the chicken-and-egg problem gets solved. Once the system is bootstrapped, all the rest can be expressed in terms of the system itself. So, there is no contradiction with Smalltalk's philosophy that everything happens by sending messages because it only becomes a Smalltalk system once it's bootstrapped.
Metaclass class class = Metaclass is a classical academic example of strange loop. But if you inquire a bit, you could find many others in Smalltalk.
Object superclass is nil which is an instance of UndefinedObject which is a subclass of Object (longer chain via ProtoObject in Squeak Object superclass superclass class superclass = Object)
The methods of MethodDictionary are stored in an instance of MethodDictionary (MethodDictionary methodDictionary class = MethodDictionary).
The name of Symbol is an instance of Symbol (works with ByteSymbol in Squeak ByteSymbol name class = ByteSymbol).
The subclasses of ArrayedCollection are stored in an instance of Array which is a subclass of ArrayedCollection (Array superclass subclasses class = Array).
Smalltalk is a SystemDictionary which points to Smalltalk via the #Smalltalk key (This is less direct in Squeak, (Smalltalk globals at: #Smalltalk) = Smalltalk).
I let you continue the list by yourself.
Whatever the implementation, the ultimate question is whether or not you can devise a self-describing system like Smalltalk without these strange loops, and you may glimpse a not so positive answer if you follow the sublinks of http://en.wikipedia.org/wiki/Kurt_G%C3%B6del#The_Incompleteness_Theorem
Related to the the bootstrap problem encountered with such system, an efficient way is to clone oneself to change oneself, and this is particularly true in Smalltalk image when you want to change base classes that you are using for changing / describing classes.
Hence my previous and concise answer which was deleted by applying the letter of the rules (https://stackoverflow.com/help/deleted-answers) more than the spirit in my opinion:
And here is how it was resolved: http://en.wikipedia.org/wiki/Drawing_Hands
Last point, I would have preferred to read, Incredible Consistency of Smalltalk, but I'm definitely biased.
Is class an object in object oriented language? How are Class methods accessed by just name of the class.method name? (internal working). Is this same as a object.method?
And If the Class is same as object (belong to object class which is super class of every thing in OO) and we instantiate it (make object of it), can we make instance of an instance of an class other than Object class.
(Mainly interested in the theoretical perspective even if practically not required ever)
Well, it depends on the language that you are using; in pure OO languages where everything is an object (e.g. Smalltalk) classes are no exception and are objects too. In other languages where classes are not considered as first class citizens they are just special language constructs or primitive types. From now on I'll use Smalltalk as a target language, due to its reflection support and homogeneous style.
How Class methods are accessed by just name of the class.method name?
(internal working). Is this same as as object.method?
Since classes are objects, they are in turn instances of a class (a metaclass). Thus, sending a message to the class is just sending a message to an object whose role is to represent how classes behave. There is a lot of literature out there, you can take a look for example here and here for some introduction.
And If the Class is same as object (belong to object class which is
super class of every thing in OO) and we instantiate it (make object
of it), can we make instance of an instance of an class other than
Object class.
I'm not sure I follow you here, but just for clarification it is not always the case that Object is the superclass of all the classes. The thing is that If you start following the relationships between classes and metaclasses, you may reach a sort of infinite loop. Different languages work this out in different ways and for example, in VisualWorks Smalltalk, Object is a subclass of nil. The thing is that nil is also an object (remember, everything is an object) and it actually represents "nothing". As you may expect, nil is an instance of a class (UndefinedObject) and it also implements some of the class protocol. As a result it can be used to represent a class form where nothing is inherited :).
Finally, I don't know if this answers your question, but yes, you can do many cool things with full reflective capabilities, like creating new classes on the fly or reshaping existing ones. I'll leave you here some documents that you may find interesting regarding this topic:
Metaclasses
Understanding Metaclasses
Debugging Objects
A class isn't an object, you can think of it as a 'blueprint' for an object. It describes the shape and behaviour of that object. Objects are instances of a class.
See here for more information.
Is class a object in object oriented language?
The notion of class is first and foremost theoretical. You can define a thing with "class" semantics even if your language does not support the formal notion of "class" (e.g. Javascript). A class is a template for an object, from which you create instances.
How Class methods are accessed by just name of the class.method name?
I'm not quite sure what you mean. Some languages support "static" or "class" methods, which are methods that are not invoked within the context of an instance of the class. So its not the same as "object.method" which is a normal method on the class where the 'this' (or equivalent) will be the instance on which the method is invoked.
Java (from comments)
For Java, there is a class called Object, and a class called Class. See this. These Java constructs are separate from the notion of Class and Object. The former are implementation details -- they are how the designers constructed the language, the latter are general concepts. So in Java, you can have an instance of an Object, where the instance is an object(the concept) of type Object(the Java construct).
A Basic notion of object means that has been allocated some memory. As devdigital said class is just a blueprint for an object which holds the bare-bone structure and determines how the object will behave when it's it will be instantiated.
Classes are just bodies(without soul) and objects are living bodies(having a soul) that interact with environment or in biological terms respond to external stimuli(public methods and properties) in an analogy to philosophy of life :)
Technically classes are just machine interpretable code residing in memory(not necessary main memory or registers). Objects are code loaded into executable memory(registers/main memory)
Not to sound like a koan, but just wondering if there are definite rules about classes and objects. I used to think classes as blueprints, and objects as the creation from them. But if a combination of blueprints creates another blueprint, does the latter blueprint become an object as well?
Your question seems a bit philosophical... :) "object" and "instance" are quite synonymous in OOP.
If I understood your question correctly, your doubt is: "an object is still an object also if created by another class that is not the same that define its type?"
The answer is "yes", an instance is an object created following the "model" defined by its class, but for many reasons you could instantiate a class in an indirect way, for example a static method (factory method of a factory class, for example) and not directly using new statement.
If you want to see some come, an easy example in Java could be:
public class MyClass {
public MyClass(){}
}
public class MyClassFactory{
public getInstance(){
return new MyClass();
}
}
In this case the instance is not returned directly by MyClass, but from its factory class. however it's an object as well...
In just about every OO environment I know, an instance is the same as an object.
It doesn't matter whether the object/instance is created by the client (such as with new) or by the class (such as with singletons or factories).
If you're talking about blueprints in the context of classes, then creating blueprints from blueprints is inheritance, not instantiation.
I've seen many other questions on this same topic but they're not very clear to me, someone new to Objective-C.
I need a plain english explanation. 'Coder speak' is much too difficult for me to understand at this point in my learning.
An instance method or variable applies to that instance. A class method (classes in Objective-C don't have variables, though they can be simulated in various ways) applies to the whole class.
Consider the quintessential Dog class, which derives from the Mammal class (and so on up the tree of life.) A particular dog has a name and a collar and an owner--those are its properties. A particular dog may -bark or -chaseBall or -buryBoneInBackyard--those are its methods.
The Dog class, on the other hand, has different methods. The Dog class has a +globalPopulation and may instantiate itself with a +dogWithDNA: factory method. The Dog class will have an +isExtinct method indicating whether the species as a whole is extinct (it's not, of course.)
In short: class methods affect the entire class, while instance methods affect a particular instance of a class.
First, Objective-C does not have class variables. There are things that act sorts like class variables modally, but they aren't true class variables (see "static variables").
In Objective-C, every class is effectively an instance of a class. Thus, a class method is simply a method that applies to the class. They can be inherited and overridden.
Instance variables (ivars) and instance methods exist on each instance. There is one ivar per instance. Instance methods can not be called on classes.
Class variables^ and class methods do not not exist on instances, they exist on the class. That means that there will only ever be one class variable in the entire application regardless of how many instances are created. Class methods can be called without an instance*, so they kind of act like normal C functions. Because class methods are not attached to an instance, class methods can not access ivars.
^ Objective-C doesn't have class variables per se. "Class variables" are effectively static global variables in C.
* technically, a class is an instance, so class methods are actually instance methods in a sense.
A class is like a mold for something, that you can fill with plaster.
So a class level method is something that you can see and reach and use, without ever having to make a single object.
An instance is like pouring plaster into the mold and getting something out. You stamp out as many as you need; an instance variable then is a place on that object to hold something, and an instance method is something you can do with only that single object, not all of them.