In the course of writing the Parallel Processing with ABAP Objects E-Bite, it turned out that the sample application I created also serves as an excellent example of what a package design should look like in order to maximize decoupling and minimize complexity.
Moreover, the gradual introduction and improvement of parallel processing allowed me to demonstrate how package design can and should be adapted over time. You can find more information about the ABAP package concept and how agile software engineers should use it in the Test-Driven Development with ABAP Objects book and the Designing Testable ABAP Classes and Packages E-Bite, respectively.
Now, let’s answer the question of why agile development considers packages so important? Imagine a monster method of a class – that is, a method containing very many lines of code. We could likewise consider a large function module or a complex report here, but, for the sake of simplicity, let us focus on the method case. You can reduce the method complexity by repeatedly extracting coherent paragraphs of its implementation to private methods. If you succeed taming the monster like this, then you end up with a monster class with way too many methods. Therefore, you continue refactoring by extracting coherent sets of private methods to global classes. If you take the single responsibility principle seriously, then you end up with a monster package with many classes. Finally, to work out (reuse) components with concise scopes, the package concept allows you to convert your monster package to a well-defined hierarchy of main and development packages.
However, for agile software engineers, ABAP packages are much more than just containers of development objects like classes. With a single flag, a package can encapsulate all development objects which it does not explicitly expose with one of its package interfaces. Multiple package interfaces make sense if there are different groups of client packages which require different sets of development objects from a server package. In addition, the server package can limit the use access to a package interface to dedicated client packages. The Parallel Processing with ABAP Objects E-Bite provides examples for all these cases and illustrates them in diagrams as shown in the figure below.
As the figure shows, the order package of the sample application depends on a package for the data access (DAO) as well as on a package of another application (API). Both depended-on packages expose only interfaces and hide their concrete implementations. The order package itself provides, next to its regular package interface PIF_ORDER, also a special package interface PIF_ORDER_T to which it grants use access only to the test infrastructure package (INFRA). This allows the test infrastructure package to access classes, but ensures that all product packages still depend only on interfaces.
Finally, packages can hide complexity. For example, the final version of the sample application in the Parallel Processing with ABAP Objects E-Bite includes an encapsulated package that hides the entire parallel processing logic with a package interface that provides only one interface with only one method. For agile development, decoupling is also important. In other words, the service of a server package should remain stable and simple no matter how often and intensive this package is refactored.