RE: what is object oriented programming -- RPG400-L

> From: Bartell, Aaron L.
>
> <Joe>
> ...(Aaron, I suggest you get these as well, because they really
> show why you
> need to start from the ground up when
> designing OO architectures).
> </Joe>
>
> If this is from my statement of "you don't need to understand OO to make
> good use of it", I didn't mean that you shouldn't learn how to
> build simple
> base objects that can be extended upon.  I have already done some reading
> from those books (mostly from Bruce's).  Note** I am not a purist OO
> programmer.

As Hans says, in some ways OO is akin to a spiritual experience.  For
reasons far outside the scope of this list (considering this post is already
on the line), I believe that most procedural programmers require an epiphany
to "convert" to OO thinking.  Your above statement leads me to belive you
haven't reached that point yet.

Because OO is actually not about objects, not entirely.  It's about a frame
of mind where code is encapsulated and interfaces are defined and everybody
communicates via messages (in the strictest sense of OO, every interaction
between objects can be though of as a message - every method call is a
message with a bunch of parameters and a return code).

Hans and I disagree on the importance of data hiding to OO principles (in
every text I've read and every person I've talked to, the common practice in
OO is to hide all data members of a class and allow access only through
setters and getters - this is probably one of the strongest conventions in
OO today, and there is good reason for it), but we agree on the importance
of design patterns.  And you can't really design an OO system without using
design patterns of some kind; they're sort of like the simple machines of OO
programming.  Where engineers think of the pulley, the lever and the
inclined plane, OO designers think of the Decorator and the Factory.

Without understanding those basic tools and how they are used, you are
likely going to build applications that look like - well, that look like my
first projects.  Procedural ideas wrapped in OO skins.  It's ugly, because
you don't take advantage of any of the real benefits of OO design.  For
example, in OO you should program to the interface.  While the exact
implementation of this is different in different languages, it in essence
means that you never directly interact with another class.  You instead
interact with an idealized version of that class which everyone agrees upon.
You don't instantiate the class either, you invoke a Factory method which
gives you an instance of an object that implements the interface.  Why is
this important?  It's hard to explain in a single post, but it buys you an
enormous amount of flexibility down the road. Is it always necessary?  No,
but until you have worked with the concept a while, you're not in a position
to be able to decide wisely.

The point is, though, that if you don't code this way FROM THE START, it's
hell to go back and rearchitect your system.  Trust me on this.

Anyway, that's it for me.  As hard as we've all tried to keep this on topic,
this thread is destined to drift farther and farther from RPG.  Until and
unless you all decide to create an OO-L list, this is my last word on the
subject.

Joe