RE: File encapsulation

 >A primary benefit of encapsulation is protection of ongoing processes from
changes to the underlying data source.
That's exactly what I said in more or less words.  The encapsulation lets
you track things coming in and going out.  When I mentioned the portion of
the Java community creating an unwritten rule for getter and setters I
merely meant that there are other methods to do the exact same thing (i.e.
how .NET accesses an objects properties), not that you should implement it
sometimes and not in others.  Sorry I was not clear in my definition the
first time around.

>Regarding your final point, a well designed file wrapper can make
downstream programming much easier.
I agree, though it would be debatable what a well designed file wrapper
looked like.  By your statement it seems you are trying to do it at the
file/table level and I  don't agree with that approach because you don't
need to be that close to the database, IMO. <buzz word alert> You should
instead be developing things in a Service Oriented Architecture approach.
Sure you could have file/table level I/O within your SOA modules, but it
becomes hard to justify because it is a mess to try and code all of the
different native db functionalities in a service program.  Take a typical
set of order files/tables and put wrappers around all of them for all of the
necessary RPG opcodes (chain, reade, read, readp, readpe, etc) and then
introduce all of the logicals that are attached to those files/tables and do
the exact same thing.  Pretty soon you have programmers dedicated to doing
file I/O programming, which if you can justify it because of other issues
(i.e. files change constantly) then that may be the way to go (I have yet to
justify it).  

Actually that just made me think of the approach I decided to take when I
went down the road you are going on. . . Only when a file became hard to
keep up, regarding changes to the structure, would I ever entertain the idea
of putting a file I/O layer in. Doing an all or nothing is like trying to
boil the ocean (which is the way I initially went but found my pot wasn't
big enough ;-)

>Typing "wkSOON = getSOON();" is no more onerous than "wkSOON = SOON;".
This is a good starting point for the discussion. What did you have to do to
get to the above statement? A chain? A read? How were those sub procedures
written that have the chain and read in them?

>In my view, the only real consideration is the impact of repeated calls to
setters and/or getters in a batch environment.
I wouldn't consider that as much of a problem as trying to keep all of the
getters and setters service programs up to date and getting them initially
written (a lot of man hours to consider there).  How do you plan on doing
signatures for new sub procedures for one? A large set of applications can
get into the thousands of tables (not including indexes, views and other DB
objects). Is it wise to write applications I/O wrappers for each of those
before you even know you need them for each specific file? 

>...creating the service programs can be delegated to a case tool.
Are there any out there that do this job well?  I have to admit that none of
my RPG code is generated nor have I used a RPG code generator, so I can't
speak to the tools usabilities whether they are good or not. I do however
use a lot of Java code generators (i.e. Hibernate class builders for a good
related example) and I must say that they are quite nice and save me a ton
of time, but Java is a much different language than RPG and Java tools are
much more abundant.

Good conversation, I think there is some good middle ground we can find here
for encapsulating in RPG.
Aaron Bartell


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Cate, Tony (Alliance)
Sent: Tuesday, November 29, 2005 9:28 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: File encapsulation

I'm not an object-oriented programming theorist, but I think your
understanding of encapsulation is flawed.  There is no point to the approach
if you're going to do it some of the time.

We're already well down the road of business process encapsulation.

Regarding your final point, a well designed file wrapper can make downstream
programming much easier. Typing "wkSOON = getSOON();" is no more onerous
than "wkSOON = SOON;". If you're referring to the creation of the file
wrapper, once a standard has been reached for file wrappers, creating the
service programs can be delegated to a case tool.

In my view, the only real consideration is the impact of repeated calls to
setters and/or getters in a batch environment.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of albartell
Sent: Tuesday, November 29, 2005 7:34 AM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: File encapsulation

 IMO there is a right way and a wrong way to do "encapsulating file access"
in RPG.  For one thing I would immediately rename the approach to
"encapsulating business processes for reuse" so staff doesn't get the wrong
impression of the end goal. 

My first attempt at creating file I/O wrappers came about because of my
introduction to Java and it's approach to guarding class variables by
putting a getter and setter in front of everything. The reasons I was told
Java did this was so that you would always have control of what the value
was being set to or so that you could massage the data as it left the class
with the getter routine. Note that the getter and setter methods in Java are
not there for providing database I/O separation but rather because a
community has created an unwritten rule that states getters and setters are
how you program in Java.

So my recommendation would not be to create file I/O wrappers but instead
find places where you are repeating same processes and model those into a
reusable service program with appropriate sub procedures.  A case in point
would be the process of getting the price for a product. Usually there are
many variables involved in obtaining an item's price and there are many
places where it is needed (Order Entry in house, Online Shopping Basket,
EDI, Quotes, etc). If the pricing routine is designed appropriately you
should be able to hide the complexities of the database I/O and all
corresponding business logic into a few sub procedure calls and reuse it for
each application set within your company.

You have to remember that in the end you are trying to save time. Going to a
low-level approach is not going save time unless all of the code is
generated for you and RPG just isn't suited for file I/O code generation
without crippling the ease of use we have with native I/O. Finding the right
mix will take a few trial and errors because there will be some programs the
become way to bulky and others will be so low-level that it takes a couple
programmers just to do the monotonous work of typing them in.

HTH,
Aaron Bartell


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Cate, Tony (Alliance)
Sent: Friday, November 25, 2005 12:01 PM
To: RPG programming on the AS400 / iSeries
Subject: File encapsulation


Our group is thinking about encapsulating file access in service programs.
Concerns have been voiced about the impact on performance such a move would
have.

Does anyone out there have practical experience with this technique that
they would be willing to share? 

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.