The next stop on our galaxy quest through Design Patterns takes us to the alternative universe known as Design Anti-Patterns. Nothing from this region is registered in the GoF catalog.
When I first began experimenting with object-oriented ABAP, I approached the challenge by taking one of my reasonably well-designed report programs written using the procedural style and converting it into a program using as much object-orientation as possible. My goal was to become familiar with the object-oriented paradigm using a familiar program, so I could compare its execution with a proven procedural counterpart. Having no experience at the time with any of the object-oriented design principles presented in this book, I simply created the same procedural program using methods in place of forms and using a single static class containing public attributes in place of a main driving subroutine with its collection of global variables. In the end, I was satisfied that I was able to get it to work using the new ABAP Objects statements that I had recently made an effort to learn, and began using this as a foundation upon which to build subsequent programs I was asked to design.
Now, years later, I cringe when I reflect upon the rookie mistakes I made with those simplistic designs and my naïve approach to writing object-oriented code. I merely succeeded in applying the use of object-oriented statements with a procedural design. Lacking any concept of instances and of classes offering a specialization of data management, I simply created one static class, named this_program, into which I placed all the processing previously contained in procedural subroutines.
However, it is exactly this path that many programmers have already taken and that many will continue to take as they struggle with the transition from thinking only procedurally to being able to think objectively. A static class offers a stepping stone from procedural thinking to becoming fluent with using the statements, before one eventually grasps the concepts of encapsulation, abstraction, inheritance, and polymorphism that typically are absent in their early attempts at designing programs with object-oriented ABAP statements. None of us suddenly become experts with object-oriented concepts simply because we have read the books or have been taught by a competent instructor. It takes time before we can regard ourselves as capable object-oriented programmers. Meanwhile, we will make mistakes along the way, which could come back to haunt us during maintenance cycles, but by then perhaps we will have gained enough experience and have learned how we should have designed the program the first time and thus can refactor the program accordingly.
My early object-oriented designs, where I defined a single static class and merely dumped all the processing logic into it without regard for whether or not the processing was applicable to the class, are examples of what are known derisively in the industry as God objects.
God object : An object that has too many capabilities and responsibilities
A God object is just one of the many types of software techniques known as design anti-patterns, techniques regarded by scholars in the industry as undesirable elements in software design. These design anti-patterns have been used over the years frequently enough to have become identified by names and reasons for avoiding their use. Perhaps you might recognize some of them:
Big ball of mud | A system lacking any recognizable structure |
Boat anchor | A component serving no useful purpose |
Gold plating | Expending effort that contributes no additional value |
Magic numbers | The use in algorithms of numbers having no explanation |
Object orgy | Exposing object internals to unrestricted access due to lack of proper encapsulation |
Spaghetti code | Components having a structure or flow difficult to comprehend |
Indeed, in our exercise programs we are using the following technique, which is regarded as a design anti-pattern:
Constant interface | An interface composed solely of constants |
We are using a constant interface to define those constants associated with the program-generated initial selection screen, an entity that in ABAP necessarily must exist externally to object-oriented components. A constant interface is considered a design anti-pattern because it often results in a component exhibiting low cohesion.
Since our constant interface contains only constants related to the initial selection screen, it does not suffer from the low cohesion it might reflect were it also to contain constants having no relevance to the initial selection screen.
Although the subject of design anti-patterns is not the focus of this book, it is useful to know that such patterns exist and that they may lurk in our subconscious until we become more experienced with how to avoid succumbing to these design pitfalls .