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.

Based on what you use in the real world, what are the key points of objects that I should focus on explaining. For example:

• Access Levels
• Inheritance
• Encapsulation
• Polymorphism
• Abstraction
• Interfaces

Answer 1

Use real life examples.

• Animal (interface)
• Mammal (abstract class)
• Dog (class)
• Your dog (object instance)

access levels: And your mom can't touch your privates, but your friends can.

Answer 2

I would go by Grady Booch definition: An Object is one which has a State, Behaviour and Identity. Member variables contribute to State; Methods contribute to Behaviour and some unique attributes contribute to identity. For eg., email could be an identity attribute for a Person Object.

Answer 3

IMHO we must first get them interested in OOP before bombarding them with all the concepts in OOP. To make them get attracted towards OOP, explaining all the concepts in OOP or showing examples of cats and dogs will not work. You need to show them the advantages by comparing a problem solved the OOP and the non OOP way. Make sure you solve the problem first the non OOP way, highlight the disadvantages, use one of the concepts of OOP to solve it. It might probably employ only one concept of OOP, but if you are able to make them feel the advantage it holds over the other method, they would themselves be eager to explore more of OOP. You just need to point them in the right direction after that. Once they are familiar with the concepts, point them towards design pattern books like "Head first design patterns".

Answer 4

As always, it really does depend on the language background they're coming from. Not every language implements OO paradigms the same way, sometimes it's possible to use an OO approach in a language that isn't stricly OO at all.

Generally, access levels are important to mention. Why should properties generally be private? What's the point of having getters and setters? This is a good place to contrast objects with collections like maps or arrays (even if they can be implemented as objects rather than primitives).

Inheritance and polymorphism should go hand-in-hand. This is a matter of abstraction, though. Explaining the difference between abstract base classes and interfaces is probably more of a language problem again -- some languages allow multiple inheritance, others only allow multiple interfaces.

Encapsulation is pretty straightforward if you got the access levels sorted out. Again, depending on the language you might want to explain inner classes and such, abstract the OO idea even further with anonymous classes maybe.

I find what works best is to start with something familiar: related functions and variables. Learning what should be an object and what object a property or method should belong to is tough, so start with clear cases.

A database handler can be a good example, or maybe an email (create a new email, set its headers and content, attach files and send it -- pretty straightforward and familiar even to non-programmers, but a perfect example for thinking in terms of objects (email, contacts; maybe even mailboxes, servers), methods (create, send, attach, set) and properties (headers, content, attachments)).

What's important is this: even if your students have some (non-OO) programming background, adjusting to OOP is a process, but "getting it" often isn't. I've heard many people describe it as a sudden event rather than a smooth transition. Of course the "calibration" is a long-term process: you need to figure out when it makes sense to create new classes and when a few temporary variables, an array or utility functions (depending on your language) will suffice, but this needs practice, not teaching.

Answer 5

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 6

I would use one example through the whole thing to build up the concept instead of jumping over unrelated examples.

That magical example would be GUI.

GUI made a lot of sense when I understood OOP after a lot of struggle.

A window is an 'object'. a button is nothing but a fancy way to say a rectangle drawn in a special way (abstraction). A window 'has' buttons. A hyperlink label 'is' a button. every Clickable thing on my Screen is a button (Interfaces). All buttons when clicked go to Stack overflow (inheritance). Except one button, which goes to Server fault (polymorphism).

And the hard part, 'Encapsulation' which is nothing but a fancy way to save the programmer from debugging :)

In the end I would stress that OOP is not the end of the world, If it does not make sense to think about something as an Object then it is NOT an Object. Because I have seen a programmer trying to build a mergesort class :D

Thanks,