<snip>
Encapsulation is a good thing.
Indeed. As a general rule, return a pointer to the program to the
structure which is managed by the service program itself (i.e. allocated
and destroyed).
The program only knows about the pointer, it knows nothing about the
internal structure. Then pass this pointer as the first argument to
procedures "GetNextCustomer", "GetParentCustomer". And if you put all
the code like this that belongs to the Customer entity into one
well-named serviceprogram then we even have a bit of OO here.
</snip>
One other possibility would be if you are on V5R4 is to use SQL and
recursion. A single SQL statement could recurse down your list and
return a list of customers.
As to a function, I would think you only need a single function passing
the Parent customer number and a constant defined in the prototype for
*FIRST or *NEXT as a second parameter.
You could, also, just pass the parent customer number to the
initialization routine that creates the array below and then you just
pass the handle to walk the linked list. No need for parent number or
*FIRST or *NEXT unless you need to walk forward or back.
As far as hiding, I have many times created an array of pointers to
point to my link list and had a function that returns an integer id.
Each call then has a parameter that passes the id number which is just a
pointer into the right array element. This array could be an array of
record and store the last position read or other information you need.
The fact that RPG/ILE is not OO just means that you have to manage your
own global storage. An OO language does that for you automatically.
Also, about returning a pointer from a service program.
I would consider this to be bad practice no matter what. The pointer can
be used to do anything and exposes the internals of your service
program.
Returning a handle that points into an array is always a much better way
Everything is managed and hidden in the service program.
The bottom line to all this is that you can write ILE solutions to
problems that do not require monolith solutions (Returning entire array,
your linked list, etc).
I think the other reason to implement and hid all the logic in a service
program is the target audience. You and I may understand linked lists
but how many other programmers do? A key concept for me is hiding
complexity.
All the complexity is hidden and the user does not need to know how it
works. Only how to use the functions. I can create very complex
solutions but the user never needs to know how it is done unless they
want to look.
The downside to service programs, if you would call it that, is that
they take a lot of work to create. It is more difficult to create a
general purpose service program than a single purpose program but the
results are almost always worth it.
midrange.com
