The Problem with Large BAdI Interfaces 

The Problem

Suppose you are faced with a large BAdI that has 50 methods (see the figure below). Of course, this does not look like a BAdI that was designed adhering to the principles of good object-oriented design, but you may still ask what is bad about such a BAdI:

Assume that in many solutions only the first three methods are needed, the others are known as optional methods, which are only used by some customers in their system. Nevertheless, an implementation of this BAdI has to implement all methods. A common result will be that the first three methods get a real implementation while the rest get an empty implementation.

Now you are faced with a problem. When the BAdI definition is modified for some reason or when there is an upgrade, in the SPAU_ENH you have to touch also the 47 methods that are empty. So you spend your time on some work that is not necessary in any way.

The Solution

The solution to this problem is not to put the methods you need and optional methods in one BAdI, but to tailor small BAdIs containing only the methods that are needed by a group of customers. Of course, this does not mean you should put all methods you need in one large BAdI if you need them for one IS. When designing a BAdI, you should adhere to the principles of good object-oriented design. Do not define gigantic BAdIs, but small ones tailored for definite problems or even parts of a problem. In any case, keep your BAdIs small, not as a means in itself, but to have manageable BAdIs that do not force those who implement the BAdI to write empty implementations. The figure below shows how you separate the methods:

When implementing a BAdI, you have to implement all its methods. This is a consequence of the fact that a BAdI defines an interface, and interfaces have to be implemented completely. Syntactically, there is no such thing as partially implementing an interface.

How to Group the Small BAdIs

When designing small BAdIs, you can face a problem caused by the fact that the BAdIs are small. Of course, you will get a higher number of BAdIs and a huge mass of BAdIs in the same namespace, and this could soon lead to a disorganized mess.

To prevent this, you need containers in which you put the BAdIs. And this is, where the (simple) enhancement spot is used. As for all the other enhancement types, this spot can be used as a container for BAdI definitions. Of course, the BAdIs are still in the same namespace, but they are structured in larger units, that is, the enhancement spots. Therefore they are easier to handle. The following figure shows how you use containers: