Re: Resort back to RPG?

Joe Pluta wrote:
> And then there are those of us who have been saying this exact same thing
> for years, and are continuing to implement it.  Bandwagon jumping always
> occurs, but if you take the time to analyze the tools, it's easy to see what
> makes sense and what doesn't.
>
> For example, take SAA.  Great concept, but its implementation basically
> chewed up 30-40 percent of a screen (or more).  Given the fact that our
> screens were already cramped, it was obvious that SAA wasn't going to fly.
> That didn't stop the bandwagon jumpers, but eventually reality took hold and
> SAA died, leaving us a legacy of some nice stamdards but thankfully no rigid
> requirements.

I remember SAA well.  It was indeed pretty much brain-dead from the
get go.  No one took it much seriously, least of all by us here in IBM.

> Java for business logic has the same problem.  The very nature of OO
> programming (the fact that your hierarchies can really only be extended, not
> changed) means that business rules don't map well to OO practices.  In
> addition, data-driven decision making (which is the bulk of all business
> logic) doesn't fit nicely into the idea of an object, since it requires a
> hugely complex hierarchy.

This is the point I really want to address in your note.  There is a
heck of a lot to OO design, and a lot of important aspects can
easily be missed on first glance.  Part of that is perhaps hype,
part is almost certainly due to poor education.  Personally, I find
myself learning more and more, and still now after roughly 18 years
of interest in the subject, I find myself still learning new things,
and still getting those "aha" insight moments.  Let me describe one
of those "aha" insights:

(First, a very quick summary of the basics of OO design.  (For the
benefit of others reading.  I'm sure you, Joe, understand at least
these basics.)  OO design basically involves charting out the
objects in some problem domain and their interrelationships.  There
are two types of object relationships:  1) The "is a" relationship.
  For example, a mammal "is an" animal.  And 2) the "has a"
relationship.  For example, a mammal "has" four limbs.)

Let's consider the objects involved in managing employees in a
company.  A naive design would have a base "employee" class and a
number of derived classes, such as "manager", "regular", "temp",
etc.  That is, a "manager" is an "employee", or a "regular" is an
"employee".  Looks fine so far, but think what happens when a
regular employee is promoted to management.  The "employee" object
must be destroyed, and a new "manager" object must then be created
for that employee.  A more appropriate design would have an
"employee" class which would contain a "role" object.  That way,
when an employee changes status, you would simply assign a different
"role" object to the employee.  This also simplifies employee
management, since new role objects can more easily be added to the
design.  "Aha"!  Inheritance has its limitations!

What's my point?  In proper OO design, one of the guiding principles
is that you should favor composition over inheritance.  That is,
favor the "has a" relationships over possible "is a" relationships.
Why?  Experience shows that the overuse of inheritance can result in
  overly complex designs that make maintenance more difficult.
Thus, the "hugely complex hierarchy" you mentioned.  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).

OO researchers have noticed that a number of patterns can be
discerned from well-designed OO applications.  These are called
"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.  (It may also help you understand some aspects of the
design of the Java language and its class library.)

As a start, I strongly recommend the following book on the subject:

Design Patterns Explained
By Allan Shalloway, James R. Trott
July 2001
0201715945, paperback, 368 pages
Addison-Wesley Pub Co.

There's lots more on the subject of Design Patterns, but this book
is a very good gentle introduction to the subject.

Cheers!  Hans