ABAP_to_the_Future

Using BOPF to Write a DYNPRO-Style Program 8.2
You’ll notice the attributes that were declared all referred to interfaces as opposed
to concrete classes, so in the constructor you’ll use factory methods to get actual
instances; the factory method takes care of choosing the appropriate concrete
class.
A transaction_manager class does what the name suggests, taking care of lots of
things you would otherwise manually code yourself, like keeping track of what
has changed and saving the record.
The service_manager class controls the business object itself and has methods to
do useful things, such as checking internal consistency and performing actions.
You’ll see most of these me thods shortly, because you’ll need to understand the
exact place the logic gets coded.
The object_configuration class is needed because the BOPF is such a totally
generic framework that you have to keep dynamically reading the structures in
your object using runtime identification every time you want to read or write
data.
The constants interface was mentioned earlier (Figure 8.2); you’ll see that Listing
8.1 references this to get the sc_bo_key value for the monster object, which is a
32-character hexadecimal GUID that says that this is indeed a monster object.
BOPF generates classes to process its various components like determinations,
validations, and actions. Because these are Z classes with public methods, you
could call the validation (or whatever) me thod directly from the controller program—but
that’s naughty from an OO point of view, because it relies on the caller
having lots of details about the internal structure of the BOPF object. Instead, you
would call an intermediate method of the business object’s service manager and
pass the manager a constant that refers to the name of the validation, determination,
or action. This presumes the name of the action (or whatever) will not
change, but the actual Z class inside the BOPF framework might, and this way the
calling program does not need to be changed.
At first glance, traditional programmers wi ll be horrified by things like service
managers, which sit between calling programs and actual business objects, saying
that this level of complexity ju st makes the programmer take more time.
However, one of the antifragile themes running through this book keeps coming
back to the fact that if a structure take s longer to set up in the initial coding
phase (5% of the lifecycle of a program) but makes things far easier in the
293