RE: Re: Resort back to RPG?

> From: Hans Boldt
>
> In proper OO design, one of the guiding principles
> is that you should favor composition over inheritance.

Undoubtedly.  I stress this when I teach OO design.


> Thus, the "hugely complex hierarchy" you mentioned.

Composition designs have as many drawbacks as inheritance hierarchies in
non-trivial applications.  I'll get back to this below.


> The reason I'm
> babbling on this topic is because I strongly suspect that you've
> fallen into the trap of overusing inheritance (as have many of us,
> including me).

I've been burnt by inheritance and composition.


> These are called "design patterns".

Yup.  I've referred to this in my previous posts, including the grand-daddy
of them all, the Gamma, et al authored "Design Patterns".


> Understanding these patterns is key to a proper
> understanding of OO design, and could help you devise good OO
> designs for you business applications, should you be so inclined to
> learn more.

Unfortunately, design patterns are for the most part at a level below that
required by application programmers.  Singletons, Factories, and so on are
either so basic as to not require explaining or inapplicable to a typical
busienss application.

For example, every RPG programmer understands a Singleton and uses them
every day - the issue is whether to implement the persistence of the
Singleton through a database file, a data area or a user space.  OO doesn't
make application decisions, which is one of the drawbacks.  There is no
common way to implement the application behavior of a class (and no, letting
a J2EE container handle it is not a solution, it's simply begging the
question).

The problem with applying OO to business applications is that it doesn't
work.  As you point out, inheritance falls apart quickly when designing
business objects.  Unfortunately, so does its alternative, composition.  For
example, in the case I discussed, the MRP generation, there are perhaps a
dozen different flags with a hundred different states.  If you program these
each using a separate class and use a hierarchy heavily dependent upon
composition, then you will be performing tests all throughout your
containing class to determine the appropriate actions.  You will, in effect,
be reproducing all the procedural code except you will have added the
overhead of the object design.

Rather than rely on your theoretical knowledge of OO design, I highly
recommend that you try writing some non-trivial application code, Hans.
Reading is good, but before you recommend a course of action, I suggest you
try applying it to a real world example.  Until you've actually written a
business application, you can't really understand what's involved.  It wuold
be like me trying to recommend a course of action in writing a compiler.
Theoretically, I know enough to be dangerous <smile>.

Joe