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.