Chapter 2. The Object-Oriented Way

Before we get into describing Theme in any detail, let's explore why it is that the object-oriented software paradigm does not provide us with encapsulation and reuse to the extent that we would like.

The basic point of this chapter is that requirements do not align with objects. To get from one to the other requires a leap or transformation of some kind. That leap hurts how easy it is to evolve a system. It is also an impediment to comprehensibility, reuse, and traceability. This is true regardless of how well you've designed your system. When a new requirement is introduced late into your development cycle, accommodating it is going to affect an unpredictable number of objects simply because your requirements and your objects don't align.

This chapter describes the basic motivation for aspect-oriented analysis, design, and implementation: We would like to be able to encapsulate units in the software that we recognize as units of interest from our understanding of the requirements. This provides us with a level of traceability between the software and the requirements that in turn helps us to ensure that we have covered all the requirements in the software and helps us to understand where changes to requirements will impact the software. We would also like to reuse such units when we come across the same requirement in different situations. Reuse is likely to significantly decrease the cost of development.

In this chapter, we explore the extent to which we can achieve software encapsulation of units of interest in the requirements with the object-oriented paradigm.