definition of OO and how (not) to use it

Wed, 06 Apr 2016 20:02:24 +0200

The definition of OO programming which I like the best
is: the coupling of data with the algorithms to modify
that selfsame data. I.e., behavior and
characteristics, encapsulated and multiplied,
given life.

C++ does this all the time with its classes, object
instances, data members, and methods to set the data
from inside the instance itself. It is a model that
comes to life. Not all problems lend themselves to
being solved by being modeled (described).
But some do!

It doesn't really matter if OO itself is implemented
as syntactic sugar or not. OO is all about interfaces
anyway, so it can be an interface to itself just
as well!

On the other hand, the best interface to an object is
the so-called "tell, don't ask". Tell the object what
it should do and give it what it needs to do it
(indirectly with references/pointers if need be).
But don't ask for what the object knows so you or
anyone else can do its job in its place - that 
gets confusing. Simple rule: avoid returning stuff,
and it is all good.

Also avoid inheritance. Never use it massively nested,
e.g. several levels like the science trees of animal
and plant wildlife. Also never use inheritance just to
reuse part of another piece of code (so-called
US-style inheritance). If that situation arises, when
you are tempted to do so, instead, out-factor the
common snippet and have both classes derive from it.
Use it inheritance logically (in terms of the human or
"real" world) but with 1-2 levels at the most!

Back to Blogomatic.