Hi Pete
The caching seems a little scary to me. I assume you don't do it if the
method gets data from a file (or whatever) which could change between the
calls.
Jim
Date: Fri, 1 Jul 2011 00:17:38 +0000 (UTC)
from: Pete Hall <pete@xxxxxxxxxxxxxx>
subject: Re: Modernising a monolith ile program
On Thu, 30 Jun 2011 08:39:07 -0500, Vern Hamberg wrote:
You call this monolithic - that usually means that everything is in one
code source - that doesn't seem to be the case here, right?
I guess everyone has their own idea about that. I consider a monolithic
program to be (a big ugly) one where everything has a global scope,
probably including many levels of nested decision points, and usually
indecipherable variable names. In our shop, it's almost invariably in
fixed RPG format.
I don't care how big a service program is, or how many procedures it
contains. I like service programs to be experts on a particular type of
information, and to contain all the methods needed to obtain and
manipulate it.
In my view, a proper method within a service module does one thing, does
it robustly, and has no external dependencies (like execution order.)
Each method maintains the data and business rules for which it is
responsible. It generally caches data so it can return the cached value
when executed multiple times with the same parameters. If another method
needs a value for an entity, it calls the getter method for that entity,
and doesn't worry about the data source, or how the data were developed.
Methods within a service module can have a "friend" relationship with the
other methods in the module, if needed, by declaring global data (usually
a data structure, record image or array of structures.) Internal
structures are not exported outside the service module. Where it makes
sense, data can be read by other (possibly public) getters, but only
modified by the single method that is responsible for it.
It works well for me.
--
Pete Hall
midrange.com
