• Enterprise Architecture
• Application Architecture
• Service Oriented Architecture

• Object-Orientation
• Patterns
• Software Process
• Java and J2EE?
• Maintainability vs. Performance
• Logical vs. Physical Design
• Chapter Synopsis
• Structure of the Heuristics
• Summary of the Heuristics

You'll also notice that many of the heuristics support each other. Usually, when you violate one heuristic, you are violating another. Conversely, when seeking to comply with one heuristic, it's very likely that you'll use other heuristics to achieve this compliance.

When I established the vision for this work, I planned to focus on those heuristics of software design that were universally applicable. That is, I was only going to write about ideas that should always be adhered to. But I realized if I would have done that, I wouldn't be writing for very long. There are very few concepts that should always be strictly adhered to, and I quickly found this to be the case. There are exceptions to every rule, and I encourage you to keep this in mind as you read through each heuristic. The heuristics solve certain problems, and some heuristics even contradict each other to some extent depending on the issue that is most important. As best as I could, I try to discuss these ideas in the Consequences section.

Pattern Structure

Each heuristic is consistent in structure to help maximize it’s readability. Each is also accompanied by an example illustrating how the underlying principle it captures is misapplied, followed by a more appropriate application. Not all sections will appear for all heuristics. In some cases, I'll suppress certain sections when a previous discussion can be referenced. The general structure of each heuristic is as follows:

• Name
  • The name of the heuristic. The name is important, since it helps establish a common vocabulary among developers.
• Statement
  • A summary describing the core principle embodied by the pattern. This statement helps establish the pattern's intent.
• Sketch
  • A visual representation showing the general structure of the heuristic applied. Usually, UML is used here.
• Description
  • A more detailed explanation describing the problem the pattern solves. The description establishes the motivation for the pattern.
• Implementation Variations
  • As with any pattern, there are subtle implementation details that quickly arise when applying the pattern to a real world problem. Implementation Variations discusses some of the more significant alternatives you should consider when applying the pattern.
• Consequences
  • All design decisions have advantages and disadvantages, and like most advice on software design, the use of these patterns must be judicious. While they offer a great deal of flexibility, that flexibility comes with a price. The Consequences section discusses some of the interesting things you'll likely encounter when applying the heuristic, as well as some of the probable outcomes should you decide to ignore the pattern. After reading through the consequences, you should have a better idea of when you'll want to apply the pattern, and when you may want to consider using an alternative approach. Boiled down, this section represents the advantages and disadvantages of using the pattern, the price you'll pay, and the benefits you should realize.
• Sample Code
  • It's usually easier to understand the value of a pattern if you first experience some of the problems that surface by choosing an alternative, yet less flexible approach. In this section, I typically present an initial solution that, while commonly used, has subtle flaws in it's implementation. Then, through a series of refactorings, the subtle imperfections in the original design are resolved. The end result is an implementation that makes use of the pattern presented.
• Related Pattern(s)
  • Most of the heuristics are fundamental aspects of object orientation and design patterns that are used daily. In this section, I’ll examine patterns similar to the one presented, and explore the similarities and differences.