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

this question is interesting ... and very complicated ... because it depends on the language you use ...

• take objective-c: an object has it's variables, only accessible from inside, and methods, such as accessors ... objective-c actually sends around messages between objects ... which gives comes at a certain cost, but allows lots of cool things, like proxies, mock objects, profiling, AOP and so forth ... in objective-c, a class is an object ... objective-c does not have the notion of access levels ...

• take PHP ... there, classes are not objects ... objects have variables and methods ... and it's totally inconsistent ... :) ... just as a bad example ...

• take Ruby ... there, everything is completely dynamic ... an object has its variables, only visible from inside, and a class, determining its methods ... you can modify that class at runtime, or even, you can assign a different class to that very object ... funky ... and also, in ruby, operators are methods of objects ... you have incredible language constructs like blocks ...

• take ECMA-Script(JavaScript for example) ... here everything is an object ... functions are first class objects ... an object has a set of properties (fully dynamic), some of which may be functions, acting as the object's methods ... you may take the method of one object, and apply it to another instead (does not necessarily make sense, but it is feasible) ... any function may be used, to instantiate a new object ... and so on ... ECMA-Script does not have the concept of access levels, but you can hide away data using closures, if necessary ... ECMA-Script does not know classes ... but inheritance is achieved through its prototype based nature ...

i could go on ... but you see my point, i guess ... many languages implement only parts of all the things that most understand as OOP and emphasize different things ... sometimes it's a weakness, sometimes powerfull ... also the semantics, of what an object is, and what a method is, is VERY different ... to not confuse your students, you should really stick to one language, or languages having exactly the same semantics, when it comes to objects, and the describe what an object is ... otherwise, they will never actually understand you model ... once they got their head around it, you can show, how OOP looks in other languages ...

i think, you should take JavaScript or Ruby (although i think JavaScript is better, and then move on to ActionScript 2, to have a typed version of it, and classes, interfaces etc. ... or start with ActionScript 2 directly), to show concepts of OOP, since they are very radical, clear and simple ... or maybe other scripting languages ...

a thing not to forget is, that it's object oriented and not class oriented programming ... chosing a language, that does not need classes in order to have objects, seems a good idea ...

• introduce objects as entities ... first just create some anonymous dynamic objects, give them some attributes and methods and play around ... maybe fiddle around with some built-in global objects, if any such things exist ... try to show, how thes objects can model a real world ... don't try to hard ... simple examples ... let them add a few methods on the run and experiment a bit ...
• once they get a hang of it and really kind of understand what objects are, explain, what a type is, first on the builtin types (if you choose the right language, any value is an object ... i think that's a good way to go) ... then explain, what a class is ... an object, or maybe just a language construct, to create objects, that are similar and have the same type ... then explain subclassing ... don't inherit car from vehicle ... don't extend fruit with apple ... it's confusing ... you have a type of objects, and you have subtypes of that type ... as in real life, science, maths ... anything ...
• then explain interfaces ... as a different kind of types, that categorize an object not by where it comes from, but by what it does ...
• once that is really understood, talk about encapsulation and access levels
• once they understood inheritance and interfaces, tell them, inheritance is cool for not writing a lot, but it does not solve all problems ... emphasize the importance of interfaces ... teach them to use interfaces as parameter types, whenever possible ... introduce composition, forwarding, proxying, delegation, etc. ... show them how nicely factories can be used to reduce dependancies on concrete classes ...
• preach decoupling, and teach them ways to achieve this ... explain them, how to build their object hierarchies, so they don't wind up with a chaotic network, instead of a nice tree, where dependancies get ever smaller, as you go to the leaves ...
• now you can safely move to languages, that are less sexy, but more mature ...

use a language, that is consistent and keeps code short and concise ... try to avoid situations, where you have n lines of code, that are mandatory, but you don't really have the time to explain them ...

in my opinion, introducing people to OOP first, is a good decision ... OOP is about modelling ... the higher the language, the more it teaches abstract thinking ... starting with procedural languages, where you maintain states in tons of variables scattered around your programm, is not good ... it takes a hell lot of time for people who really learned procedural programming, to move on to OOP ...

well, this was a little more, than i actually inteded to write ... hope it helps at least ... :)

greetz

back2dos