How to explain an object?

Question

It\'s been years since I thought of this, but I am training some real juniors soon and need to explain what an object is to someone who doesn\'t know what it is.

B

Answer 1

Stick with Booch's definition: An object has state, exhibits some well-defined behavior, and has a unique identity. I noticed that others posted this already, but people made comments regarding some objects not needing state, behavior, or identity which I disagree with. An object has state in the sense that some programmer defined amount of memory has been allocated for it, behavior in the sense that it can react to messages being sent to it, and identity in the sense that it can be assigned an identifier. Which actually sounds a lot like Kay's explanation of a lot of little specialized computers communicating with one another.

I also agree with the few posts that mention first understanding the concepts of procedural programming, because the work in an object-oriented program is still done at the procedure level. The difference is the level of abstraction at which the programmer can write the program. In object-oriented programming, programming at a higher level of abstraction is the ability for the programmer to make concepts that span state and behavior, in any combination, explicit. Which obviously requires an understanding of how to implement concepts using state and behavior.

The next major concept I would tackle is generalization. An object choosing which behavior to invoke in response to being sent a message, at run time, is what allows for generalization. Generalization occurs when a programmer hides the details of how to accomplish a similar concept in two distinct ways behind one uniform message.

From here I would move on to encapsulation, inheritance, and polymorphism. And from there on to more high level concepts. I just feel that keeping everything focused specifically around how these concepts help you solve problems is important for retaining them.

Answer 2

I prefer the approach used in "Object-Oriented Design and Patterns" by Hortsmann. If I recall correctly, the approach was to read a problem statement and identify the objects, their methods, relations, and other components using a simple pattern. For instance, an object is a noun, so all nouns would be candidate objects.

The book itself is highly recommended. After establishing what an object is, it uses some clearly defined and simple examples to discuss inheritance, interfaces, and many design patterns like the singleton.

Haha...so I guess I really suggest you let someone else do it... an author(ity).

Answer 3

objects (usually) have state, behaviour, and identity.

basic o-o programming principles are encapsulation, inheritance, and polymorphism.

basic o-o design principles are here: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Answer 4

I might start with anonymous types or something like JSON to demonstrate that objects are just collections of properties. Talk about cohesion.

What if we want a bunch of these objects? Classes/constructors/instances.
What about functionality? Methods.

Then demonstrate the problems that occur from a lack of encapsulation. Show how getters/setters/private fields alleviate the problem (maybe move to a typed language if you've been using JSON)...

Then show how inheritance allows code reuse--maybe show a sample of inheritance by actually re-typing (with the keyboard) the functionality to demonstrate what a pain it is. Show that you can change something in one authoritative place when things are well-designed.

Then introduce polymorphism--because inheritance is sometimes insufficient. Include interfaces here.

Try to use real-world examples--either from the code-base they'll be working on or from your own portfolio. As you go, demonstrate refactoring and other good practices. "Hey, I keep repeating this pattern--I should consolidate it somehow".

Answer 5

I prefer using real-life examples that you can actually interact with: a dish-washer, a car, ...

These things also happen to have a very strict interface: a car (in Europe :)) has an Acceleration pedal, a Break and a Clutch. You can ask for it's current speed.

Encapsulation: no need to know how the engine works if you know the interface. A good thing that you don't have to tinker the engine yourself, too.

Polymorphism: you can drive a Lada and a Porche using the same interface. This means you are a polymorphous driver :).

Note: it's taken me years to differentiate the concept of an interface from inheritance. I would say: leave inheritance out for a while: most of the time code reuse is achieved better by composition (though that's a whole other discussion).

Answer 6

I like the original metaphor used by Alan Kay, who coined "object-oriented programming": Objects are like cells in a body. They are each programmed with their own behaviors and communicate by passing messages to one another, which they again respond to with their own internally defined behavior. No one cell knows what's inside another — they just know how to handle their own tasks and communicate with each other.