On 12/13/2010 3:55 AM, David FOXWELL wrote:
-----Message d'origine-----
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] De la part de Morgan, Paul
2) Your procedures are too closely coupled together which
isn't very modular. GetAutLevel is returning the UAUTNV
value retrieved by SetUserInfo. See
http://en.wikipedia.org/wiki/Coupling_(computer_science) for
a discussion.
So, now that we've all read the article, would anyone care to show me how my code could have been less tightly coupled? I can't see it.
The utopia we seek is a place where GetAutLevel would return the
authorisation level as a parameter or return value. By having UAUTNV as
a global variable, every part of the program needs to be aware not to
modify that variable; every function and subroutine needs to know
something about the insides of all the rest.
If UAUTNV (suitably renamed) were returned as a parameter, we would no
longer worry that a CHAIN elsewhere might alter the value. One of the
biggest problems with a global variable coming out of a file is someone
inserting a CHAIN where one never used to be. Imagine that your account
structure has parent and child accounts (Carrefour corporate
headquarters is the parent; the stores in Lyons and Toulon are child
accounts).
Today, let's say the code only checks the credit for a parent account:
1) Verify account number
2) GetSecLevel
3) if level high enough, continue
Tomorrow, we need to add some code to get the child account's delivery
address:
1) Verify account number
2) GetDeliveryAddr(child)
3) GetSecLevel(parent)
4) if level high enough, continue
This code looks great from this level, but it turns out that since both
subprocedures CHAIN to ACCOUNTMASTER, both subprocedures alter global
variables (the fields in the ACCOUNTMASTER file). When the first CHAIN
occurs, the fields contain the delivery information for Lyons as well as
the security level. After the second CHAIN, the fields contain the
delivery information for headquarters, as well as the security level.
If we assume that the next step is to print the order, it will not be
what we want.
The programmer here needs to know all the places a CHAIN occurs to
ACCOUNTMASTER and then make sure that he does not alter the sequence of
events. In a loosely coupled set of procedures, it would not matter
what order they were processed in. Nor would it matter what variables
were used inside the procedures. Compare these:
childSecLevel = getSecLevel(child)
parentSecLevel = getSecLevel(parent)
getDeliveryAddress(child: childAddr1: childAddr2: childAddr3)
with these:
getSecLevel(child)
(alters UAUTNV)
getSecLevel(parent)
(alters UAUTNV)
getDeliveryAddress(child)
(alters NAME, ADDRESS1, ADDRESS2, ADDRESS3, UAUTNV, PHONE<
ACCTOPENEDDATE...)
Really, all three routines change all those variables, but with a name
like getSecLevel, I might forget that, and imagine that only the
security level is changed!
Typically, we worked around this sort of problem in the past by
immediately storing the global fields in a work variable:
getSecLevel(child)
childSecLevel = UAUTNV
getSecLevel(parent)
parentSecLevel = UAUTNV
getDeliveryAddress(child)
childAddr1 = address1
childAddr2 = address2
childAddr3 = address3
Here, the code doesn't really care that UAUTNV again has the value for
the child record.
Hope that helped.
--buck
midrange.com
