What Is An Object

From DefinitionsForOo

I feel somehow misunderstood. My point was not to try DefinitionsForOo (that may indeed not be possible), but to ask a somewhat more basic question: WhatIsAnObject? I know, that probably everyone here has an understanding of what it is (otherwise we couldn't program OO at all). And I myself have programmed OO in assembly in the 68K micro kernel that was part of my dissertation (creating virtual method dispatch tables with macros). I have an idea of what an object is: MemoryWithMeaning?. But is it really that? Or how would you define an object? -- GunnarZarncke

That's an easy one -- an "object" is "what I do object-oriented programming on". -- ts

   x= new Object();

That would be an object. But it depends on the meaning of the question. Exactly what is the context in which you ask "what is an object"? Depending on the context, you might get surprisingly different answers. Let me give you a practical example: some consultant came in to a shop to teach UML, OO, Design Patterns, etc. To be fair, the teacher didn't stand a chance anyways, given the time allotted by the management, but one interesting exercise was given: play with minesweeper and with solitaire (the well-known games from windows) and come up with a UML model for the "objects" inside those games. At the heart of this modeling exercise is the question of WhatIsAnObject. So rather than looking at this question in the abstract (an investigation likely to lead nowhere, similar to the question WhatIsTheTruth? or WhatIsTheMeaningOfItAll?), let's look like we were reimplementing solitaire in an OO language, and let's see what "objects" we see inside it. Let's assume the questions about method (XP vs BDUF) are set aside, some will not start with objects and classes that model the domain, but will start with a use case, others with a test, etc, it doesn't matter, the question is "what are the objects that will end up living in the runtime of the solitaire game?" -- CostinCozianu

Conceptualization of an object is a way organizing perception. An object is whatever you view as an object, even if you can't clearly delimit where that 'object' ends and some other object begins (a'la "lake" and "atmosphere" and "solar system"). An object is not the signal you utilize to perceive it... but you can reify signals, too. All perception is ultimately organized via use of patterns, and every object is a pattern, but we tend to separate spatial 'noun' patterns from temporal 'verb' patterns, distinguishing the former as objects and the latter as actions.

What we call a 'method' is an action that a typical agent or actor (another pattern... WhatIsAnActor? deserves its own page) can perform in association with an object (e.g. upon it, with it, etc). I have distaste for the whole concept of 'methods' being attached to the objects. I much prefer to associate actions with the actors.

Use of objects in ObjectOrientedProgramming duals the conceptualization of objects. Rather than objects being an organization of perception, objects become an organization of data to perceive... state clumped together at some physical location in memory or attached by pointers. The result of producing an object in this manner is the production of a real object. Performing actions on these real objects affects them in real ways. These real objects might, themselves, be utilized to reflect or model some other object-system (like toy soldiers on a map); however, because this is a real object and NOT an organization of perception, it lends itself much better to simulation and other forms of projecting a 'real' object onto the world than it does to modeling. (See ObjectVsModel).

An object is a unit of reuse. What are you going to need to call over and over? That's an object. The great thing is that this forces you to think of the practical effects of your objects at design time, rather than being worried about things like having an accurate representation of this, that or the other. -- RichardCordova

Isn't that a class?

I think classes form a subset of such units and could in most cases be considered reusable sets of invariants (and even this may depend on the language of choice). -- rc

"An object is a dynamic instance of a class declaration." From a Simula manual in 1969. I have not seen the manual, but wherever it came from, I like the way "dynamic instance" and "class declaration" bring to mind the separation between two states of software systems - activity and definition. -- PeterLynch

I like how it's an operational definition that avoids all sorts of philosophical issues.

What about dynamic OO languages that don't have a "class" distinct from an object? That definition is language-centric. OO does not require "classes" (if it handles similar features in other ways).

A nice thing about operational definitions is that you can have a different one per language.

Is there a bit of hair-splitting going on here? Would it improve the Simula definition to change it to "An object (or its equivalent in another OO language) is a dynamic instance (or its equivalent in another OO language) of a class (or its equivalent in another OO language) declaration (or its equivalent in another OO language)" DeleteWhenCooked

There is no non-dynamic instance in such languages, and thus no equivalent. Staticness is just a language feature.

CategoryObjectOrientation CategoryDefinition