RE: File encapsulation

I'm not an object-oriented programming theorist, but I think your
understanding of encapsulation is flawed. A primary benefit of
encapsulation is protection of ongoing processes from changes to the
underlying data source. 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.