Jeff,
You describe a good framework very well, one that I use for my Getters.
And you will soon discover that describing Getters of a block of fields
in this way is fairly simplistic.
It is when you start dealing with the Setters, specifically, the
multi-field Setter that clarity of code (and longer names using ellipses
. . . ) will help.
Say for example, one person can only update Product Description, while
another person can update Product Description and Reorder Points, and
another person can update Product Description and Reorder Points and
Product Cost Rollups.
For efficiency for the last person, do you want to do one update to the
Product Record -or- three updates to the product record. That is your
call. But the goal is for the "next programmer in" to not have to look
too closely at the lower level update routine to understand what is
updated from the screen, what is updated by an internal routine (like
the Product Cost Rollups) and what is
All_Product_Fields_Subject_to_Update. Your descriptive Procedure Names
should provide the meaning.
1) The service program doesn't have to be only getters and setters.
It can have whatever I want.
2) I could have 'group' setters and getters. Example: virtually
every time I want the item description, I also want the pack, size,
brand, extended description, and class, ie, other fields that describe
the item. So the service program could have a GetItemDescriptiveInfo
subprocedure. And a GetItemInventory to get cases, units, and weight on
hand fields. And a GetItemMovement to get all received MTD/YTD as well
as shipped MTD/YTD fields. And a GetItemCosts to get last, average,
market, and all other cost fields. And on and on, ad infinitum.
midrange.com
