Rob: I create and use the file encapsulated service programs. I also expose it to the other developers and analysts so they can both use it and understand how it works. The way I name the procedures pretty much reflects RPG opcodes, so knowledge of RPG I/O is likely pretty important.
Jon: Like I said, my gets and sets are created instantly so it's no skin off my back that a few extra procedures are loaded into memory. And if I need a Get procedure and there isn't one, I can add it. That said, in the address example, it's not like I'm suggesting you only ever use a group of single gets and sets to retrieve the data. To me a service program that encapsulates a file is a business object, so any logic pertaining to the data stored in that file is a solid fit for the service program. I wouldn't limit it to I/O procedures only, a getAddress procedure would definitely make sense. I also see nothing wrong with adding in a procedure that would make data retrieval easier for a particular program getItemInquiryScreenData (and in that case it could be passing a data structure instead of a list of fields.
However I do suggest that within that business logic gets and sets are used so any logic that is field specific and is found within the get/set would not be missed.
I will admit that I haven't done extensive research on the use of gets and sets conceptually. I've simply found benefit to doing it this way over time.
-Kurt Anderson
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Jon Paris
Sent: Monday, March 01, 2010 12:58 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: RPG400-L Digest, Vol 9, Issue 184
On Mar 1, 2010, at 1:20 PM, rpg400-l-request@xxxxxxxxxxxx wrote:
Yes, that is what I thought you would do and it would work well.
Honestly
though, I am still not enamored with any file encapsulation strategy
I have
seen for RPG. I guess I am coming around to a getter/setter approach
though, simply because it offers the most flexibility.
I tend to favor the "business objects" approach. For example - I might
want to retrieve the shipping address - I sure as heck don't want to
implement that as a series of getter requests - yuck! Different
groupings can be defined ranging from (say) a whole invoice, to a line
item, to invoice totals, to ...
If the purists insist I can implement getters and setters under the
covers to populate the "object" but even the most hardened of OO
bigots seem to have moved away from the "Thou shalt always have a
getter and setter for every column in thy database" silliness.
Jon Paris
www.Partner400.com
www.SystemiDeveloper.com
midrange.com
