Software Development and the Object-Oriented Paradigm

Few would disagree that the object-oriented paradigm is one of the most important contributions to software development in its history. Those of us who remember developing software without objects most keenly appreciate their value. Everything to do with a "thing" is all in one place! When we want a "thing" we already have in one application to be used in another application, we can just pick it up and use it! And there are many more benefits besides.

To this day, we both remain big fans of objects. But of all the benefits associated with object-oriented development, the two of encapsulation and reuse that we hinted at above were not selected lightly. Can we really always put everything to do with a thing all in one place? Have you ever found that there was some piece of processing that did not seem to fit in any one particular class, and yet it did not feel as if it belonged in a class in its own right either? This is probably because it was too tightly coupled to behaviors in many other classes.

Think about, for example, objects that require some transaction management. It is difficult, if not impossible, to modularize all setup, communication with a transaction manager, and rolling back that may be needed to handle transactions. This is because all objects (or methods in objects) that require transaction management need to be aware that their operation is impacted by a transaction context and must behave accordingly. In other words, transaction-handling code must be placed in every object that needs it. Take a look at the code you've written in the past, and you will probably find many examples of similar (if not the same) pieces of code repeated in different places. The common, though compromised, solution to a problem like transaction management is to copy the code into the different places that need it. Code copying then results in poor modularization for much of your code and leaves you with considerable maintenance and evolution headaches. This phenomenon is also known as scattering, as code for a concern is scattered across multiple parts of the system.

In addition, from a reuse perspective, modules that contain code relating to many concerns are likely to be less generally useful in different situations. The phenomenon where multiple concerns are intermixed in the code is known as tangling.

Of course, good use of design patterns will help you encapsulate in many situations, but you will find the repetition and concern-mixing phenomena even where design patterns are well used. Ultimately, you will always encounter processing that relates to and impacts upon many portions of a system.