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

Start with explains what Object-Oriented-Design means...

- It means that you take a real-life situation you want to model using software and copy its model into a software models.

Each entity within the actual situation (the one that exists even if there was no software) gets a representative in the software's design - an object. (Abstraction)

Each kind of entity is a class, every entity of the same kind is an object of the same type.

* Give an example here from a field that interests your students and continue with same example. - Try to make it a funny one.

Each object should model only one entity and that entire entity, if you change one object it should not affect another. (Encapsulation)

Next, you think of the relationships between the entities, is one a specific type of another (inheritance), is one a part of another (composition), can one go in and out of another (aggregation).

Next, you think about the main things the entities do (methods) and how to define them (properties/fields).

Now take an example for inheritance from the example you gave earlier and explain polymorphism - you can do the same thing that you can on the general type as you can on any specific type that inherits it and you can ask every specific type to do what you can ask the generic type to do, but they can do it whatever way they want to (overriding).

Next interfaces, here perhaps use animals - not all animals have tails to wag, but some do. You want to model a man, a dog, a cat, a spider and a dinosaur. All are (or were) animals but the generic type - animal can't wag its tail, a. because there is no such thing as a generic animal (it's abstract) b. because not animals can WagTail(). However, all those that can WagTail() can implement the interface IWagTailable.

Access levels:
if something is part of an entities description or known actions (if it is in its contract) - it's public.
If an object keeps some information that only it needs to know about or is allowed to know about or does something no one knows about - it's private.
If not everyone is allowed to know about it but its inheritors are allowed to know about it - it's protected.

Maybe get into constructors (how to initialize the object's definitions) and destructors (freeing the memory/file handles/connections it's holding).

Maybe also properties - kind of like fields, only you can limit access to read-only, write-only or even make something happen when reading or writing.