pattern0_RemoveDependancy

/*ref: E:\ChenyxFiles\2014.Study.TrainingCertificate\SAS.Victoria\SAS.DS2\SASUniversityEdition\myfolders\DesignPattern\DependencyInversion\The Dependency Inversion.Principle.pdf
The Dependency Inversion Principle:
A HIGH LEVEL MODULES SHOULD NOT DEPEND UPON LOW LEVEL MODULES.
BOTH SHOULD DEPEND UPON ABSTRACTIONS - e.g. common data, common param

Traditional Structured Analysis and Design:
tend to create software structures in which high level modules
depend upon low level modules

Consider the implications of high level modules that depend upon low level
modules.
It is the high level modules that contain the important policy decisions
and business models of an application.
when these modules depend upon the lower level modules, then changes to
the lower level modules can have direct effects upon them;
and can force them to change.


High Level Modules Re-use:
Moreover, it is high level modules that we want to be able to reuse. We are already
quite good at reusing low level modules in the form of subroutine libraries. When high
level modules depend upon low level modules, it becomes very difficult to reuse those
high level modules in different contexts. However, when the high level modules are independent
of the low level modules, then the high level modules can be reused quite simply.

This is the principle that is at the very heart of framework design.


The High Level Modules knows nothing of the low Level Modules;
Those details are isolated by interface(or common variable, parameters)
*/

%MACRO callTwice(aString, outputVariant);
%DO i=1 %TO 2;
%&outputVariant(&aString.);
%END;
%MEND callTwice;

%MACRO simplePut(stringToOutput);
%PUT(&stringToOutput.);
%MEND simplePut;
%MACRO upcasePut(stringToOutput);
%PUT(%UPCASE(&stringToOutput.));
%MEND upcasePut;


%callTwice('testString', simplePut);
%callTwice('testString', upcasePut);