|
michaelbarb wrote: an object is a set of one or more instances
I don't like that at all!
I think it just depends on the circumstances which sounds more natural (to me);
"If we add this property to the Customer class"
"We'd need to save the Customer object to the database"
"That instance needs to be saved to the database"
So object is really more generic than instance.
michaelbarb wrote: A class is much more than just properties. It is also methods.
Sure, of course - I meant properties in a generic sense - Properties, methods, constructors, events, references interface implementations etc. etc. are all just properties of an object - like diameter, colour and the ability to bounce are all properties of a ball.
MVVM # - I did it My Way
___________________________________________
Man, you're a god. - walterhevedeich 26/05/2011
.\\axxx
(That's an 'M')
|
|
|
|
|
Wrong forum.
Mostly 3. Definitely not 1 or 2.
In my opinion... "object" is not strictly a technical term, but a very high-level concept, analogous to "thing". Some object may be defined in some language as a class, a struct, a collection, whatever.
Like "data structure" on steroids.
|
|
|
|
|
Object is unit of storage in computer memory - it is simple concept that means it has size and address: that is all folks you need to know what object is. Most of us keep forgetting that we program box filled with wires, transistors, diodes etc.
Class is template of data type (includes both fields and functions) and it is programming abstraction of real world problem it attempts to solve.
Class that has been created or instantiated takes shape (becomes an object that you can "touch", talk to - meaning send and receive messages, move, delete etc.) in computer memory that the program can work with.
There should not be any confusion what object is among programmers. Unfortunately most programming books is using some weird concepts and examples regarding OOP which confuses everybody and it is not even funny.
|
|
|
|
|
If you study the original papers about object oriented programming you will find that PIEBALDconsult is closer to their view. I think most programming books have followed this concept. It is a little harder and more abstract to understand. Over time things have changed and the word object more often attached to a an instance as you state. Because of all the confusion about the word "object", it continues to be an ambiguous term. The only unambiguous software terms are "class" and "instance".
Wow, you can touch something in computer memory. Are you kind of like Tron? . . . I a apologize for my sarcasm I just could not help my self.
To be really exact there are two kinds of instances. There are virtual instances that exist in computer memory. There are physical instances that you can really touch and maybe even eat. For Thanksgiving I think I will stay with a physical turkey. I will be full but I will bet you will still be hungry after eating a virtual turkey.
I also at times have trouble separating the physical and virtual worlds  . I keep having to remind myself they are different. Maybe someday physical and virtual instances will merge.
So many years of programming I have forgotten more languages than I know.
|
|
|
|
|
There is no ambiguity. If you forget to instantiate your programming abstraction i.e. create memory storage you will get execution error stating that memory object cannot be found (exact wording depends on the sense of humor of the compiler programmer).
Not all languages will use class or instance as a valid term. Most of the confusion stems from academics who cannot program and do not understand underlying technology but can write poetry and create log and confusing lectures on something very simple.
PiebaldConsult is very generic and incorrect in my opinion.
|
|
|
|
|
Academics "create long and confusing lectures on something very simple" 50/50 shot. Not at all sure about that poetry thing.
So many years of programming I have forgotten more languages than I know.
|
|
|
|
|
Object is a universal term that can be applied to any level of abstraction.
It can be an instance of a class, a smartphone, a record in a database, a document, an archive of documents and a pixel on your screen. But an object can also be other things like a rock, an animal or a song.
A rock doesn't have to fit in the classification systems that scientists created and a song doesn't have to fit in the artist/genre system that the music industry has created. These objects are not (strictly) instances.
So every instance is an object, but not every object is an instance.
Instances always come from classes, but objects don't have to.
Objects can also be born out of chaos.
.
|
|
|
|
|
0bx wrote: Object is a universal term
Probably the most "correct" explanation I've come across. At least IMO ... which is probably the problem, there's no "opinion" shared by everyone. At best it's shared by most, though that particular "object" is hard to find.
To turn this into a specific programming simile. To me the value inside the RAM position pointed to by an un-initialized pointer is still an "object" even though it might have no meaning in any form of any class inside the program. It certainly isn't an "instance" of any of them, except if by random chance it was.
|
|
|
|
|
michaelbarb wrote: Of course we have to follow there definition in that class but we are wondering what the real answer is.
Which is one of numerous complaints about education - they don't teach you how to think, they teach the wrong things, etc. How much more fruitful it is to actually explore what object, class, and instance actually mean!
So, to you question, I realized a long time ago that when writing articles and teaching OOP, there is a lot of sloppiness regarding object and class, and very few people actually even use the term "instance." So here's my definition.
A class defines a type on which operations can be performed and which also describes its relationship with other classes. Relationship is very important!
An object is an instantiation of a class. Note the use "instantiation", related of course to the word "instance", but I want to avoid the specificity of the term "instance".
I try to use the word "instance" when I refer to a specific object. We can think of objects as abstract (not the way OOP uses the term abstract) instantiations, such as a "User object". But I'll use the word "instance" when I refer to a specific, instance of an object, such as "the 'Marc Clifton' User instance."
What I have found confuses developers (both noobs and experienced devs) is when "object" is used to refer to both a class and an instance - in fact, some very smart people I know fail to make the distinction and this can lead to all sorts of design / architecture problems when they don't realize that there is a distinct difference between the definition of a class (ie a type) and its instantiation.
So, that's my 2c. 
Marc
|
|
|
|
|
Thinking in C++;Bruce Eckel
Object is unit of storage in memory that has type, size and address so it can be referred to, copied, deleted, moved or act upon; it can send/receive messages (using functions).
Class is programming abstraction of real life problem. Class is a design template and design concept of a compound type that has to be put to work by assigning memory space for variables and function code. Once class is instantiated in the memory it becomes object (or objects with multiple instances or through inheritance, polymorphism etc.). At this moment class transitions from programming abstraction to reality (object) because it executes on the hardware for the desired effect.
|
|
|
|
|
Member 10088171 wrote: Object is unit of storage in memory that has type, size and address so it can be referred to, copied, deleted, moved or act upon; it can send/receive messages (using functions).
I disagree. Mr. Eckel is confusing an instantiation with its behavior. An object cannot inherently send/receive messages unless the class defines that behavior. Furthermore, some objects cannot be copied, deleted, moved, etc. A class doesn't need to provide any behavior at all - it can simply be a container for public fields! And lastly, and object does not have a type. If you look at memory in C++, can you distinguish between an integer and a double? No. In languages that support reflection, yes, one can determine the type of an object because somewhere there is a "database" of what object in memory is associated with what definition (the class, aka the type.)
So, with all respect, Mr. Eckel doesn't know what he's talking about.
The rest of your quote (I assume it's a quote) is also flawed.
Member 10088171 wrote: Once class is instantiated in the memory it becomes object
What about classes with static methods? These don't require instantiation. Are they objects or classes?
Marc
|
|
|
|
|
Instantiated is not equivalent with application programmer action. In case of static methods and fields the compiler does it in the background. At the runtime it is occupying memory and it is an object as well and integral part of OOP.
Object has a type defined by its class and at the core of OOP is compound type consisting of fields and functions (if any as you pointed out).
Sizeof operator will distinguish between int and float/double and C++ has features that are similar to reflection (RTTI). In fact anything you do in any language post C++ is C++. You are just not aware of this because certain complexities of C++ are hidden from modern programmer and rightly so.
Object is occupying memory and each and every object can be copied, moved etc. Just give me pointer to it.
What is confusing for most programmers? Programming abstraction which is class that does not exist unless object is created based on class design meaning that chunk of memory for data and code is assigned and then executed on the hardware. The designer creates classes but the actual work is done by objects residing on hardware.
I do not mind disagreements but to my astonishment none of the posts above was concrete enough to correlate programming abstraction with constrains of underlying hardware. This only confirms that the mumbo jumbo written in most programming books on OOP is truly confusing and able to fool experienced programmers.
|
|
|
|
|
Object is an heavily overloaded term.
So, let's try to put things into perspective.
"Object" was first introduced as a CONCEPT, as in Object-Oriented Programming. In this model, you have "stuff", which we'll call objects, that implements a program structure and logic merging procedures AND data on the same "thing". Or object, so to speak. In this new paradigm, we call procedures as Object Methods, and data as Object Properties, linked together as it makes more sense (before this the paradigm said you have code structured in procedures that manipulates data, which existed independently).
Then, based on this conceptual model, a lot of really smart people created computer languages.
Each one of them used this new paradigm as it seemed fit to solve problems.
So "objects" morphed into Classes, Instances, hierarchy, etc.
But, let's face it: Object sounds a lot better than Instance or Class, so, sometimes, people used the abstract concept of object to refer to something that was actually implemented (like Bruce Eckel in the quote from before).
So, the answer to "what is an object?" is: Anything that has Methods and Properties, merging those two really different things.
Really, really simple.
You're asking the wrong question: An Object is NOT a Class, nor an instance.
Exactly like as a function is not an Algorithm. A function can implement an Algorithm, pulling the concept into the "real world", even if not in a tangible form.
But in some languages a Class IS an object (e.g. if you have static methods and properties).
In .NET, both classes and class instances are Objects.
In Python, EVERYTHING is an object.
Conclusion: it's more a matter of asking the right questions.
|
|
|
|
|
Having static properties and methods does not make something an object. In C++, Java and C# such members are thinly disguised globals.
In Smalltalk, classes really are objects. They have methods and data, and can be manipulated at runtime (e.g. sending a message to add a new method or slot to a class).
(Of course System.Type IS an object - but that is fairly unrelated to the use of static members).
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
In C#, classes can have properties and methods: they are called static properties and methods.
They can be manipulated at run time, exactly in the same way as instances: you can change property values and call class methods.
There is no dynamic typing in C# (except for the dynamic type, but let's ignore this for the sake of this discussion).
So, a class in C# can be an Object (I was going to write "is a", but "can be" is more correct), as for the "object" definition.
|
|
|
|
|
Not at all.
A normal method of a class (an instance method) has a hidden "this" parameter passed at run time. Any virtual methods defined on the class use "this" to provide access to the vtable, used to resolve virtual methods.
In contrast, a static method has no "this" parameter at all, it does not get passed a reference to the class object. In this sense, they are exactly analogous in the way they are implemented to global variables and functions. The only (slight) benefit offered is a degree of encapsulation.
C#, C++ and Java do resolve virtual methods dynamically, by looking them up in a vtable at run time. That is the definition of polymorphism.
Its not as dynamic as message resolution in dynamic languages, but its all they offer.
Gilad Bracha (one of the people who defined the JVM) is eminently more qualified than me to point out the issues with this, and has done so eloquently over at Room 101[^].
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
99% correct. Everything is right, except for the first line: "Not at all". 
They are implemented differently, yes. But this has nothing to do with the definition of Object. You seem to fail to completely grasp the difference between the concept of object and the implementation of the concept in the language.
If "An object is something that has methods and properties", you must accept that classes in C# are, in fact, objects. Special ones, implemented differently, but the concept has nothing to do with the implementation.
Static methods can access static variables and nothing else. This is the exact definition of object.
Right or wrong, useful or dangerous, like it or not 
I agree with everything you say, but it's not a point, just a technical digression.
Classes are objects? Let's see...
It has properties? Mmmmm, yes, it can.
It has methods? Again, yes.
Ipso facto, in C# a class can be an object. Everything else is simply judging the pros and cons of the actual implementation (which I agree with you 100%).
Bye!
|
|
|
|
|
OK, in which case they are just extremely badly designed objects. They inhibit testability, break the Single Responsibility Principle (because a "class" now declares 2 objects), the Open-Closed Principle (because they inhibit "open for extension"), the Liskov Substitution Principle (because they cannot be substituted by anything), the Interface Segregation Principle (because a class cannot declare an interface for static members) and the Dependency Inversion Principle (because they cannot be abstract).
So, use of statics breaks every single one of the SOLID principles.
Alan Kay (who coined the term Object-Oriented) emphasises that message-passing (polymorphism) is crucial to object-oriented programming. An object that cannot be used polymorphically is at least breaking the spirit of OOP, if not the definition.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Agreed, 100%. 
I was not telling in any way it's a good idea to use a lot of statics.
I was just referring to an "object" strict definition.
|
|
|
|
|
A very interesting discussion. You both have proven the point of the original question most eloquently. Object is a very ambiguous term. Its meaning depends on the context of which is used.
I wonder what the above debate would look like if you could not use the word object and could only use the terms class and instance. 
So many years of programming I have forgotten more languages than I know.
|
|
|
|
|
Couldn't be bothered looking it up on Wikipedia?
Wikipedia[^]
It's a better coverage than you're likely to get in any discussion here - I've noticed many inconsistent answers already.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
I started with Wikipedia. I also looked in several other places. At the conversation shows there is considerable disagreement/confusion on what an object is. There is no confusion on what a class and instance are.
In total I think robocodeboy got it right. This opinion is base not only on this thread but also other research. There are several others in this thread that said similar things. Robocodeboy had the most complete statement but still missed one important point. In most object-oriented systems, Object is the base class from which all other classes are derived. It further reinforces everything robocodeboy said.
Most important, I was able to successfully argue the point with my professor. He conceded that object was an ambiguous term and now feels that the only proper terms are class and instance. Thanks all for the help.
So many years of programming I have forgotten more languages than I know.
|
|
|
|
|
The use of Object as a base class is, in my opinion, irrelevant.
An object is simply something that has state and behaviour. The state is typically encapsulated.
C++ has no "Object" class, but can be used for OO development.
The exact definition will vary by programming language. For example in Smalltalk, an object is pretty well anything that exists in the program at runtime - even classes are objects (instances of the class Class). The only way in ST to manipulate objects is to send them messages. It is important not to come up with a definition that excludes Smalltalk, as that is the context in which the term "Object-Oriented Programming" was invented.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
I think you just confirmed my conclusion:
. . . . Object is an ambiguous term. The only non-ambiguous terms are class and instance which we should use more often.
I do not think there is a single definition for object. Its meaning depends on the context of the discussion, the language, etc.
Since most often C++ is used in a Microsoft environment, then in general you can say that the base class of all classes is Object. It only shows there is another definition for the term Object. That is the relevant point. Please note the phrases "most often" and "in general". There are probably exceptions. Still, I suspect that even other implementations of C++ have a base class Object.
I have looked around and find Object is often the base class in many implementations of Java. Even some of the newer versions of ancient Lisp/Scheme that have added OOP use Object as the base class. I was very surprised at how consistent that usage is.
So many years of programming I have forgotten more languages than I know.
|
|
|
|
|
Unfortunately, class and instance may be unambiguous (or less ambiguous anyway), but don't generalise well as not every object-oriented language has classes.
Both JavaScript and Self support object-oriented programming in which slots (member variables) and methods are defined directly on objects.
As far as I am aware though, every object-oriented programming language supports objects that hold (ideally encapsulated) data and respond to messages (method calls, member function invocations) in some way. That pretty well sums up the role of an object. The rest is all how particular environments implement that.
I'd dispute that "most often C++ is used in a Microsoft environment". I suspect its used much, much more on Linux and (in the form of Objective C++) on Macintosh and i-Whatever platforms. Its also used in a vast number of embedded systems ranging from phones to mars rovers.
While Microsoft's MFC class library is rooted in Object, their ATL library is not. Apple use an NSObject as the root of theirs (although not every class needs inherit from NSObject).
Most C++ coding actually tends not to use class hierarchies that much - most of the C++ classes I've encountered either do not inherit anything, or from a base class that does not inherit from a common "Object" class. This becomes particularly necessary in the presence of multiple inheritance. Indeed most of the standard C++ library does not even define the base classes. For example, a library must provide a std::vector class, but that class may nor may not inherit from other classes as an implementation decision - it simply has to offer a certain interface (better described in C++ terminology as a Concept). Indeed many objects in C++ are pretty abstract - like iterators, containers, etc. which all behave similarly but have no relationship through inheritance.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
