Re: Encapsulating file access in Service Programs

On Thu, 2004-09-02 at 14:23, Richard Rothe wrote:
> I am beginning to encapsulate file access in a "Service Orirtented
> Architecuture" as described in a previous post by Aaron Bartell.  It
> is working very well.

Encapsulation has become one of my favorite designs, I use it
extensively.

> What is the preferred method of providing a return code of the file
> operation to the calling program ?  Should I provide a return code on
> every procedure that I write ? 

For functions that don't return a specific value (like a getter), I tend
to return a "successful/not-successful" indicator.  Like Aaron
mentioned, this makes sematntic use of the code very easy.  About the
only time I don't include a return code at all is on a lot of the
setters, because the prototyping handles the basic error checking.  If I
need something specific, say a verification, then I will include an
indicatored response.  An advanced technique of my Encapsulation service
programs is to include a "retrieveLastError" procedure, so if something
like this fails I can recover a message at will (pull rather than push).

> Or, just provide a procedure to determine the status separately ? 
> Like PartIsFound for determining if a part is in the Item Master.  

Again, this is the semantic use of procedure names and is, IMHO, the
only way to go.  The beauty is that I can use this procedure internally,
say in a setter proc, or externally from another program.

> Also, I've seen where others have standardized on always passing data
> back using the Procudure interface and never parameters claiming that
> the parameters should only be used for input to the procedure.  If
> multiple fields need to be returned, a data structure is used.

I've actually standardized in the opposite direction.  I very rarely use
anything but CONST for my procedure parameters.  I don't want unexpected
changes to the parameters in my calling programs.  I only have one
procedure that passes back multiple parameters, and I do that by using
the return value for the main one and a pointer for the second, so the
parameters are still all "pass-in" only.  If you do pass DSes back and
forth, put them in a /copy so they are the same.

Joel
http://www.rpgnext.com