- Why Patterns?
- Why Design Patterns?
- Why Java?
- Why UML?
- Why a Workbook?
- The Organization of This Book
- Welcome to Oozinoz!
- Source Code Disclaimer
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Organization of This Book
There are many ways to organize and to categorize patterns. You might organize them according to similarities in structure, or you might follow the order in Design Patterns. But the most important aspect of any pattern is its intent, that is, the potential value of applying the pattern. This book organizes the 23 patterns of Design Patterns according to their intent.
Having decided to organize patterns by intent raises the question of how to categorize intent. This book adopts the notion that the intent of a design pattern is usually easily expressed as the need to go beyond the ordinary facilities that are built into Java. For example, Java has plentiful support for defining the interfaces that a class implements. But if you want to adapt a class's interface to meet the needs of a client, you need to apply the ADAPTER pattern. The intent of the ADAPTER pattern goes beyond the interface facilities built into Java.
This book places design pattern intent in five categories, as follows:
- Interfaces
- Responsibility
- Construction
- Operations
- Extensions
These five categories account for five parts of this book. Each part begins with a chapter that discusses and presents challenges related to features built into Java. For example, Part I, Interface Patterns, begins with a chapter on ordinary Java interfaces. That chapter will challenge your understanding of the Java interface construct, especially in comparison to abstract classes. The remaining chapters of Part I address patterns whose primary intent involves the definition of an interface—the set of methods that a client can call from a service provider. Each of these patterns addresses a need that cannot be addressed solely with Java interfaces.
TABLE 1.2: Categorization of Patterns by Intent
|
INTENT |
PATTERNS |
|
INTERFACES |
ADAPTER, FACADE, COMPOSITE, BRIDGE |
|
RESPONSIBILITY |
SINGLETON, OBSERVER, MEDIATOR, PROXY, CHAIN OF RESPON_SIBILITY, _FLYWEIGHT |
|
CONSTRUCTION |
BUILDER, FACTORY METHOD, ABSTRACT _FACTORY, PROTOTYPE, MEMENTO |
|
OPERATIONS |
TEMPLATE METHOD, STATE, STRATEGY, COMMAND, INTERPRETER |
|
EXTENSIONS |
_DECORATOR, ITERATOR, VISITOR |
Categorizing patterns by intent does not mean that each pattern support only one type of intent. A pattern that supports more than one type of intent appears as a full chapter in the first part to which it applies and gets a brief mention in subsequent sections. Table 1.2 shows the categorization behind the organization of this book.
I hope that you will question the categorization in Table 1.2. Do you agree that SINGLETON is about responsibility, not construction? Do you think that COMPOSITE is an interface pattern? Categorizing patterns is somewhat subjective. But I hope that you will agree that thinking about the intent behind patterns and thinking about how you will apply patterns are very useful exercises.