|This outline replaces the OldIntroduction.
Also see FutureVisions.
"Find the dependencies -- and eliminate them." Quoted from JoelOnSoftware.
- Enterprise Architecture
- Application Architecture
- Service Oriented Architecture
You can read the manuscript's Introduction here.
When you architect and design a system, you are making decisions that will impact the long term survival of the system you're developing. Make the right decisions, and your system will adapt to the changing business climate it must support. But make the wrong decision, and you'll likely be forced to scrap the project, or undergo a complete re-write. The heuristics in this book present practices that will help you make better decisions when designing software. Usually though, there is no black and white answer to what it takes to fashion a high quality design. Instead other forces such as your environment, system requirements, and team makeup dictate the right decision. In other words, the right decision for one project may not be the best one for another. Understanding the consequences of your decisions is vital, and I take special care to discuss the various tradeoffs of applying each heuristic by factoring in these other forces.
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.
- Software Process
- Java and J2EE?
- Maintainability vs. Performance
- Logical vs. Physical Design
- Chapter Synopsis
- Structure of the Heuristics
- Summary of the Heuristics
General structure of each pattern will be similar to the following.
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:
- The name of the heuristic. The name is important, since it helps establish a common vocabulary among developers.
- A summary describing the core principle embodied by the pattern. This statement helps establish the pattern's intent.
- A visual representation showing the general structure of the heuristic applied. Usually, UML is used here.
- 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.
- 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.
About the Samples - In some situations where I am attempting to illustrate a particular point, I've compromised the design in another area to help simplify the example. In making these compromises, I make sure not to compromise the point I'm trying to get across. When these situations arise, I try to point this out.