The right OO (OO is NOT useless)

Ah nuts. This got a bit long... What the heck... Here goes my "send"...

I just don't see such a significant difference between OO and procedural 
that has
been portrayed in these discussions.
I agree with the reasoning of this paragraph 99%. 8-). 

On 07/05/2004 at 02:43:19 PM, java400-l-bounces@xxxxxxxxxxxx wrote:
For example, in pricing you often have to know how much a client has
bought in a certain period.  This is historical information.  You may
even have to know which store he bought from, in order to provide
quantity discounts.  In an OO environment, if you haven't already made
that information available to the class that calculates price, you will
have to modify the interface.  For example, if you only provided the
item and customer number to the pricing class, then you will need to add
the store number.  And as has been shown in every study of OO
programming, changes to the interface are the single most expensive
thing in OO development.  Whereas in a procedural program, it's simply a
call to another server.
--- end of excerpt ---

Its that last 1% that I think may have resulted from a slight 
simplification that has 
characterized some posts in this discussion.

We all think things through quite a bit more when designing than what 
we've been 
talking about in these posts, right?  And we summarize here for 
readability/clarity
and to make OUR point instead.

For example, if you accept the logic:
        "In an OO environment, if you haven't already made that 
information 
        available to the class that calculates price, you will have to 
modify 
        the interface"

The over-simplification might be the:
        "in a procedural program, it's simply a call to another server"... 


The part that is left out that I would add might also be:
        "if you haven't already made that information available to the 
_procedure_ that 
        calculates price, you will have to modify its interface too."
Right?


You guys like criteria by which to judge posters...
I only have 10 years post-college experience here at IBM developing the 
system APIs and
code in OS/400 (i5/OS) related to Java (JDBC, JTA), Threads, transaction 
processing 
and Qshell, system APIs and code. I have never written a business 
application, but only 
some of the supporting infrastructure/plumbing.

I'm a firm believer that PURE OO tends to be a poor / religiously driven 
model that
drives massive flame wars (like other religious topics).

While I view OO in general with a more pragmatic approach in which it 
servers as a 
really good model. I don't have proof or examples to back it up, but it 
has been my practice 
that it makes me more productive to have language constructs that helps 
enable the 
good procedural development models that I've always done in the past.

Typically, JUST LIKE the procedural model where you probably pass 
around or reference a control block/structure of information applicable to 
the 
task of pricing, there would probably be a similar thing in the OO  model. 


If that 'thing' happen to be an object or class, you would design changes 
to its interface 
so that they are additions, NOT changes to existing behaviors, thereby 
minimizing the 
impact of the dreaded interface change and only effecting the guy that 
wants to use it. 

You'd do this in exactly the same way you would add a field to an existing 
structure
or have that procedure grab new data that it didn't use before.

Its just programming. You do the exact same stuff whether there are 
objects/classes
or structures/procedures. I believe that to get too stuck on one path or 
another is a 
mistake from a pragmatic point of view. 

I view the namespace versus procedure/macro/type/structure naming 
conventions 
that were mentioned in this discussion as anther good example. 

Its not exactly the same in practice, but that doesn't really matter, 
logically it IS the same.
Good procedural programmers do the structured/rigid naming that makes them 
and 
their user's more productive. Having the language help me do it seems to 
make me 
more productive in the same ways. It also lets me spend more time on other 
tasks.


= = = I got off track a bit in the following, but left it in... 
= = = Doing that could be a mistake.
There are only 2 goals.
1) Sell and continue to sell software, hardware, xyz
2) Anything in support of #1 that the market demands. 
This perhaps includes, but does not necessarily include one or more
of the following: Real world solutions, maintainability, time to market, 
robustness
security, uniqueness, customer satisfaction, others....

Its hard for me to admit to myself, but I always have to beat myself over 
the head
with the following when I go to far down what I call the "golden cadillac" 
path:
        I don't believe that #2 EVER includes beautiful or elegant designs
        unless they foster one of the items already listed in #2.


Whew.. Please no flames. I attempted at every point not to come across
like I was attacking one front or another.


"The stuff we call "software" is not like anything that human society 
  is used to thinking about. Software is something like a machine, and 
  something like mathematics, and something like language, and 
  something like thought, and art, and information... 
  but software is not in fact any of those other things."
Bruce Sterling - The Hacker Crackdown

Fred A. Kulack - IBM eServer iSeries - Enterprise Application Solutions
ERP, Java DB2 access, Jdbc, JTA, etc...
IBM in Rochester, MN  (Phone: 507.253.5982   T/L 553-5982)
mailto:kulack/us.ibm.com   Personal: mailto:kulack/magnaspeed.net
AIM Home:FKulack  AIM Work:FKulackWrk 
MSN Work: fakulack/hotmail.com (replace email / with @)