RE: Using STATIC -- RPG400-L

> From: Hans Boldt
>
> First, well of course, in a distributed environment data is pretty
> much "hidden" to begin with.

I think of "distributed" in a broader sense - but you're right, I probably
should have used the term modular.


> The important OO concept here is not really the "hiding" of data per
> se, but rather the "encapsulation" of data.  A simplistic definition
> of object is that it is a set of data combined with a set of methods
> for dealing with the data.
>
   <SNIP>
>
> OK, it can make maintenance a bit easier, but I believe this just
> adds support to my assertion that if you want to implement an OO
> design, you should use an OO language.

If you're using OO techniques solely for encapsulation, it's pretty
applicable to any language.  Polymorphism and inheritance require more
infrastructure, and if your business solution really requires either one,
you're right, time to move to Java (or Python <grin>).


> I'm not really sure what you mean by "strict OO design".  The
> definitions for what is an OO language usually refer to things like
> encapsulation, polymorphism, and inheritance.  Not all OO languages
> implement them all in the same way, and so some people argue whether
> or not particular languages are really OO.

OO programming and OO design are different issues.  You and I both know that
you can take a perfectly good OO language then write a completely procedural
program in the constructor.  This is bad OO design carried to an extreme.
Extending the model (adding methods in subclasses) is a "less bad"
technique.


> Anyways, I do see your point about adding methods in subclasses.
> When you do that you tend to move away somewhat from polymorphism in
> your design.  And in OO languages with compile-time type checking
> (like Java and C++), you end up having to up-cast your object
> references.  Lots of up-casting does seem to be a characteristic of
> bad OO design.  (Languages with run-time type checking allow you to
> avoid up-casting, but that doesn't necessarily make your design any
> better!)
>
> On the other hand, adding methods to sub-classes is what happens
> when, for example, you implement particular interfaces in a Java
> class.  And, some OO languages even provide you the flexibility of
> adding attributes and methods to particular objects at run-time. The
> concept of "mix-in" classes is common in some languages.  Having the
> ability to add attributes to particular instances at run-time spares
> you the trouble of defining sub-classes.

Adding public methods to an interface means that your interface is not
complete, and that you then cannot code to the interface.  Coding to the
interface is the most basic benefit of OO programming, and anything that
breaks that paradigm reduces the benefit.

Mix-in classes scare me, personally, because I'd be tempted to use them to
cover up my hierarchy mistakes <grin>.  But we could go 'round and 'round
about those topics - pick the language that best suits your programming
style and use it.  Java happens to fit mine quite nicely (if only subclasses
inherited their own copy of static variables instead of sharing them with
the superclass).


> Funny, I see lots of examples in books of business logic implemented
> using OO models.  On the other hand, I do see your point.  Business
> logic tends to be tied in very closely with a database.  Although
> there is lots of hype about "object-oriented databases" (and other
> supposedly better DB systems), the reality is that the (32 year old)
> relational database model is *still* the best we have.  Merging a
> relational database design with an object-oriented design can be a
> non-trivial impedance-matching problem, especially with older, non-
> normalized databases.
>
> Still, with a bit of thought, and a proper relational database
> design, you can easily come up with ways to map persistent objects
> to rows in your database.  I've even noticed that, to some extent,
> inner joins can be used to simulate polymorphism.

Unfortunately, mapping objects to rows is only a relatively small part of
business applications.  Business applications are about performing actions
based on the contents of that data, and often very different actions based
on the content of a single field (or even a combination of fields in
different files).  Trying to map these complex conditional actions to a
fixed class hierarchy is quite difficult.

Now, the concept of mix-in classes would actually make this easier.  Even a
syntax like JavaScript, where you can add methods to an object dynamically,
might be better for business programming.

That's why I think Java is best suited for data transformation (such as
presenting EBCDIC database data to the user in ASCII HTML pages), while RPG
is better suited for business logic processing.

Joe