RE: "Real ILE"

Chris Bipes wrote:
>But I have also self studied on Object Oriented Programming.  When to
use >Modules and Service Programs is a very valid question.  Well there
are >several way to look at it.  Where do you want to define your
business >logic? Is the same code used in multiple programs?  Will
multiple users be >executing the same code from several different
programs at the same time?

That's where it seems to get difficult.  I may write a procedure to
update a file, for example, and it occurs to me that this same kind of
update might happen in more than one application, so maybe I should put
it in a service program or something.  But then, I can't really forsee
the specific needs of the "future" application which doesn't really
exist yet, so I don't know how to make the procedure "generic" enough to
avoid having to write a slightly modified copy of the same thing later,
which would seem to defeat the purpose. 

Another difficulty is the fact that we probably have several
applications out there already which could benefit from the procedure.
Is there value in rewriting all of those to use it ?  

Our manager had our PC guys give us a two hour run-down on OO and .Net
one day, and they talked about classes where you could have a parent
class and child classes which inherit everything from the parent, but
can have modifications of their own.  I don't know if ILE has a
counterpart to that.  It sounds cool, but then it also sounds like
something that needs some serious organization to keep track of. 

I keep wanting to keep things simple by putting them all in one program.
One of the things I like best about /free is the way it simplifies using
QCMDEXC.  Now I can write the whole string out instead of having to
concatenate a bunch of constants together, so I'm more likely to use it,
where in the past I would have called a CL to execute commands.  

But I get the impression that my preference for being able to read a
program like a novel runs counter to the way object oriented programming
works.  It's just a little difficult to see how all this re-usability
really works out in the real world.  I can understand it in terms of
little utilities like date converters and such, but we were doing that
in RPGIII by calling the utility program and passing parms.  

Maybe I would see it more clearly in the context of real application
design.  Our shop, like most I expect, uses third party software
(written in synon produced RPGII code), and our job is to write
interfaces, reports, and workarounds to make it function for our
business needs.  That's part of where my earlier comment about "real
programming" comes from.  It seems like "programmer" is a relative term
that describes a very wide variety of different skill levels.  Applying
that term to myself seems like calling the local handyman a "builder" or
worse, an "architect".  

There's a pretty good, though somewhat bizarre, discussion of some of
these concepts in a strange work called the Programmer's Stone, which
can be found at http://www.reciprocality.org/Reciprocality/r0/.  The
crux of it is a discussion of thinking styles, where "mappers" are the
visionary types who can see the big picture and understand why things
need to be the way they need to be, and "packers", who tend to memorize
lists and see things in a linear fasion, step 1 leading to step 2, with
no concept of what step 5 might be like until step 4 is reached.  

I think one needs a pretty strong "mapper" mentality to do good
programming, especially good programming design.  But I also think our
world is so immersed in information technology that a place must be
found for the packers as well.  Ideally, all programmers would be
mappers, but I think that the best which can be achieved is for every
shop to try to find one or two good mappers to do the design, and lots
of packers to implement it.  

Greg