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

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.