Re: File Read in Subprocedure WAS(Re: More on RPG style)

Matt

I think that is what Jon is saying. I also like the object idea - let the object do the individual setting and getting, but give you application a larger, higher-level construct. Precisely what you described. This seems the raison-detre of object-oriented design - work with objects, entities, whatever.

I've always thought one can write things in an object-oriented frame of mind, it's just harder when the language doesn't support it intrinsically. But there is no reason not to (did I say NOT?) put in structures that accomplish the same kind of thing. Maybe not the full-blown encapsulation and inheritance things, but in that direction.

Vern

MattLavinder@xxxxxxxxxxxxxxxxxxx wrote:

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!
...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.

Pardon my ignorance, but not sure I follow completely. I know this is an
RPG list so forgive me for talking PHP for a moment...

I usually only have setters and getters for every field in PHP because I
use a component to generate the object, but I certainly add "getters" to
format data in a more relevant way. For instance, there might be a
getShippingAddress that puts the full address together from several fields.
On the setter side, I might code a setShippingAddress that breaks the
address into its individual components and sets the appropriate database
fields.

Is this the kind of strategy you are talking about or something more
involved?

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________