ABAP_to_the_Future

Calling BAdIs 6.5
When you compare Listing 6.4 to Listing 6.2, you’ll see that the logic is no longer
welded together. Before, there was a convoluted IF/ELSE construct in which each
branch had values for the country, the monster type, and what routine to call
based on the first two. Now all three are separated: there’s some code to work out
the country, some code to work out the monster type, and some code to decide
what to do with this information. Each part of the program is doing one thing
only, as per good object-oriented design.
Note
You could go even further and put each of the three sections in its own method, thus
allowing you to change the logic inside one section without affecting the other two.
This example doesn’t do this only becaus e it would have obscured the point being
made.
The benefits of such an approach are as follows: If a new customizing value is
added for a new country, then you don’t have to change the part of the program
that gets the information about what type of monster you have. In addition, if a
country changes the way it deals with a given monster type or a new country
comes along with a totally new method ofmonster handling, then you don’t have
to change the part of the program that deals with a given type of monster. This is
the open–closed principle on steroids.
Instead, if you have to add a new countr y to the system, then you create a new
implementation of the BAdI that handles country-specific behavior. The calling
program remains unchanged. If a new activity needs to be performed (such as
sending a message to a new external sy stem), then you ad d a new implementation
for any affected countries. Figure 6.29 shows how you define a complex filter
such that the BAdI gets called if you’re in either the United Kingdom or Australia
and are dealing with a standard monster.
Figure 6.29 Complex Filter
251