The package cohesion group consists of the following design principles: the Reuse/Release Equivalency Principle (REP), the Common Closure Principle (CCP), and the Common Reuse Principle (CRP). This group deals with the principles that define packaging approaches based on class responsibilities (i.e., how strongly related the responsibilities of classes are).

REP makes release granularity equal to reuse granularity, CCP says classes that change together belong together, and CRP says classes that aren't reused jointly shouldn't be grouped together.

The package coupling group consists of the following design principles: the Acyclic Dependency Principle (ADP), the Stable Dependency Principle (SDP), and the Stable Abstractions Principle (SAP). This group deals with principles that define packaging approaches based on the packages' collaboration (i.e., how much one package relies on or is connected to another).

ADP prohibits forming cyclic dependencies among packages, SDP says package dependency should be allowed to reinforce package stability, and SAP says stable packages should be abstract packages.

Design heuristics derive from the practical experience of OO developers. They normally lie on top of design principles but can interrelate with them or even underlie design principles. Heuristics can extend design principles to several specific implementations. That's why they're on the pyramid along with design principles.

As design principles, heuristics are grouped by their application: class structure, object-oriented applications, relationships between classes and objects, inheritance relationships, association relationships, etc. Heuristics are less fundamental than design principles, but they clarify, explain, and expand design principles.

Both design principles and heuristics can be controversial. In other words, some design principles and heuristics have internal dissension, while others contradict each other. For example, conforming to the Open/Closed Principle can be expensive and lead to unnecessary complexity - the class model should be pertinent to a specific context. What do designers get if they achieve conformance? The answer is the greatest benefits of the OO paradigm - flexibility, reusability, and maintainability. Another example - the Liskov Substitution Principle restricts the use of inheritance while the Open/Closed Principle embraces it.

But for all the controversy inherent in design principles and heuristics, they still give the OO designer such a powerful and systematic basis for robust design that the resulting OO model created with their "help" is of immeasurably better quality than the ones built on just basic OO principles.

Design Patterns

The top level of OO design pyramid represents design patterns.

There are 23 basic design patterns identified by "Gang of Four" (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides), 21 core J2EE patterns identified by the Sun Java Center, 51 patterns of enterprise application architecture identified by Martin Fowler et al., and 65 enterprise integration patterns. There are also a lot of patterns specific to particular problem domains.

Design patterns represent common structured solutions to design problems solved in a particular context. They're a guide to good design practices and span a wide range of solutions from general topics like object lifecycle and structure to more specific themes such as presentation, business, data, and integration tiers, data transfer, state management, message construction, routing, channels, and transformation. Each pattern describes intent, motivation, applicability, structure, participants, collaborations, consequences, and implementation, using one of the common notations (most often UML).

To manage design patterns better and simplify their application to real systems, all patterns are categorized. Categories reflect the approach to group them together. For example, the "Gang of Four" (GoF) patterns generally considered fundamental to all other patterns were categorized by their authors into three groups: Creational, Structural, and Behavioral. Java practitioner Steven John Metsker categorized these same patterns into different groups: Interfaces, Responsibility, Construction, Operations, and Extensions.

The rule of thumb is to try to apply patterns where application design would benefit from performance and flexibility. Sometimes, however, designers have to choose patterns based on just one "benefit." For example, to improve performance, designers should always apply the core J2EE patterns of Data Access Object, Front Controller, Session Façade, Service Locator, Transfer Object, Transfer Object Assembler, Value List Handler, and Composite Entity.

In most cases, it's possible to come up with appropriate design patterns for particular problems. Still, there are situations where design patterns either don't exist or offer an inefficient solution. In that case, the solution may rest with design principles and heuristics.

Putting It All Together

The sections above described the content of each OO design pyramid level. Interdependencies between pyramid levels are represented by a complex graph that confirms their controversial semantics. As seen in Figure 2, which represents relationships between the first and the second levels (basic OO principles and OO design principles), some OO design principles depend on multiple basic OO principles while others are drawn based on other considerations.

As such, trying to draw the dependencies in such a graph is impossible. So a more appropriate methodology would be viewing these design pyramid levels and their relationships from the context of their application. Using this methodology, we can represent such relationships with this simile. If we take a car engine domain as an example, then we can think of the basic OO principles as the ones defining reciprocal-to-rotary motion conversion principles. This answers the "why" question and explains why the system works the way it works.

We can think of OO design principles and heuristics as answers to the "what" question because they unfold what to do to achieve design harmony. This is similar to the answer on what to do to build an internal-combustion engine.

At the top level of the OO design pyramid, we find the most effective approaches to solving generic and specific problems in certain contexts. We can think of this level as the one answering the "where" question. It's like picking the most efficient engine constructions for particular consumer requirements.

So different levels of the OO design pyramid tackle different aspects of OO design. Experience shows that one can't leave any of them out without running the risk of loosing something important. Applying the elements from the upper levels without aligning them to the lower levels can lead to design flaws, while applying elements from the lower levels without knowing the upper levels can increase design time (potentially at a lower quality), since designers would be forced to "reinvent the wheel" (see Figure 3).

• Table 1
• Table 2
• Table 3