From the Book:This book is for developers that know Java and that have had some exposure to the book Design Patterns. The premise of this book is that you want to: Deepen your understanding of the patterns that Design Patterns describes. Build confidence in your ability to recognize these patterns. Strengthen your ability to apply these patterns in your own Java programs.Why Patterns?A pattern in is a way of doing something, a way of pursuing an intent. This idea applies to cooking, making fireworks, developing software, and to any other craft. In any craft that is mature, or that is starting to mature, you can find common, effective methods for achieving aims and solving problems in various contexts. The community of people who practice a craft usually invent jargon that helps them talk about their craft. This jargon often refers to patterns, or standardized ways of achieving certain aims. Writers document these patterns, helping to standardize the jargon. Writers also ensure that the accumulated wisdom of a craft is available to future generations of practitioners.Christopher Alexander was one of the first writers to encapsulate a craft's best practices by documenting its patterns. His work relates to architectureof buildings, not software. In A Pattern Language: Towns, Buildings, Construction, Alexander provides patterns for architecting successful buildings and towns. His writing is powerful and has influenced the software community, partially because of the way he looks at intent. You might state the intent of architectural patterns as something like, "to design buildings." But Alexander makesit clear that the intent of architectural patterns is to serve and inspire the people who will occupy buildings and towns. Alexander's work showed that patterns are an excellent way to capture and convey the wisdom of a craft. He also established that properly perceiving and documenting the intent of a craft is a critical, philosophical, and elusive challenge. The software community has resonated with Alexander's approach and has created many books that document patterns of software development. These books record best practices for software process, software analysis, high-level and class-level design. Figure 1.1 lists books that record best practices in various aspects of software development. Figure 1.1: Many authors capture, categorize, and convey software development wisdom in the form of patterns. Subject Title Authors Software Process Patterns Process Patterns: Building Large-Scale Systems Using Object Technology Scott W. Ambler More Process Patterns: Delivering Large-Scale Systems Using Object Technology Scott W. Ambler Object Modeling Patterns Analysis Patterns: Reusable Object Models Martin Fowler Object Models: Strategies, Patterns and Applications Peter Coad, Mark Mayfield, David North Architecture Patterns CORBA Design Patterns Thomas J. Mowbray, Raphael C. Malveau Core J2EE Patterns: Best Practices and Design Strategies Deepak Alur, John Crupi, Dan Malks Pattern-Oriented Software Architecture, Volume 1: A System of Patterns Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects Douglas Schmidt, Michael Stal, Hans Rohnert, Frank Buschmann Design Patterns AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis William J. Brown, Raphael C. Malveau, Hays W. McCormick III, Thomas J. Mowbray Applying UML and Patterns, Second Edition Craig Larman Concurrent Programming in Java, Second Edition: Design Principles and Patterns Doug Lea Design Patterns Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides Design Patterns for Object-Oriented Software Development Wolfgang Pree Pattern Hatching: Design Patterns Applied John Vlissides SanFranciso Design Patterns James Carey, Brent Carlson, Tim Graser Smalltalk Oriented The Design Patterns Smalltalk Companion Sherman R. Alpert, Kyle Brown, Bobby Woolf Smalltalk Best Practice Patterns Kent Beck Java Oriented Java Design Patterns: A Tutorial James W. Cooper Patterns in Java, Volume 1 Mark Grand Compendia The Pattern Almanac 2000 Linda Rising Pattern Languages of Program Design James O. Coplien, Douglas C. Schmidt Pattern Languages of Program Design 2 John M. Vlissides, James O. Coplien, Norman Kerth Pattern Languages of Program Design 3 Robert C. Martin, Dirk Riehle, Frank Buschmann Pattern Languages of Program Design 4 Neil Harrison, Brian Foote, Hans Rohnert This list of books is not comprehensive, and new books appear every year. If you are choosing a book to read about patterns you should spend some time reading reviews of available books and try to select the book that will help you the most.Why Design Patterns?A design pattern is a patterna way to pursue an intentthat uses classes and their methods in an object-oriented language. Developers often start thinking about design after learning a programming language and writing code for a while. You might notice that someone else's code seems simpler and works better than yours does and you might wonder how they achieve this simplicity. Design patterns are a level up from code and typically show how to achieve a goal using one to ten classes. Other people have figured out how to program effectively in object-oriented languages. If you want to become a powerful Java programmer, then you should study design patterns, especially those in Design Patterns.Design Patterns describes 23 design patternsthat is, 23 ways of pursuing an intent using classes and objects in an object-oriented language. These are probably not absolutely the most useful 23 design patterns to know. On the other hand, these patterns are probably among the 100 most useful patterns. Unfortunately, there is no set of criteria that establishes the value of a pattern, and so the identity of the other 77 patterns in the top 100 is a mystery. Fortunately, the authors of Design Patterns chose well, and the patterns they document are certainly worth learning. GoF You may have noted the potential confusion between design patterns the topic and Design Patterns the book. The topic and the book title sound alike, and to distinguish them many speakers and some writers refer to the book as the "Gang of Four" book or the "GoF" book, referring to the number of its authors. In print it is not so confusing that Design Patterns refers to the book and "design patterns" refers to the topic. Accordingly, this book avoids using the phrase "GoF." Why Java?This book gives its examples in Java because Java is popular and important, and because Java will probably be the basis of future generations of computer languages. The popularity of a language is recursive. Developers invest their learning cycles in technology that they believe will last for at least a few years. The more popular a technology becomes, the more people want to learn it, and the more popular it becomes. This can lead to hype, or overexcitement about a technology's potential value. But Java is more than hype.At a superficial level, Java is important because it is popular, but Java is also popular because it is a stride forward in computer languages. Java is a consolidation language, having absorbed the strengths and discarded the weaknesses of its predecessors. This consolidation has fueled Java's popularity and helps ensure that future languages will evolve from Java rather than departing radically from it. Your investment in Java will almost surely yield value in any language that supplants Java.The patterns in Design Patterns apply to Java because, like Smalltalk and C++, Java follows a class/instance paradigm. Java is much more similar to Smalltalk and C++ than it is to, say, Prolog or Self. Although competing paradigms are important, the class/instance paradigm appears to be the most practical next step in applied computing. This book uses Java because of Java's popularity and because Java appears to lie along the evolutionary path of languages that we will use for decades ahead.Why UML?Where challenges have solutions in code, this book uses Java. But many of the challenges ask you to draw a diagram of how classes, packages, and other elements relate. You can use any notation you like, but this book uses Unified Modeling Language (UML) notation. Even if you are familiar with UML it is a good idea to have a reference handy. Two good choices are The UML Users Guide, and UML Distilled. This book also provides an appendix the bare minimum of UML knowledge that you need for this book.Why a Workbook?No matter how much you read about doing something, you won't feel like you know it until you do it. This is true partially because until you exercise the knowledge you gain from a book you won't encounter subtleties and you won't grapple with alternative approaches. You won't feel confident about design patterns until you apply them to some real challenges.The problem with learning through experience is that you can do a lot of damage as you learn. You can't apply patterns in production code before you are confident in your own skills. But you need to start applying patterns to gain confidence. What a conundrum! The solution is to practice on example problems where mistakes are valuable but painless. Each chapter in this book begins with a short introduction and then sets up a series of challenges for you to solve. After you come up with a solution you can compare your solution with one given in the "Solutions" chapter of this book. The solution in the book may take a different slant from your solution, or may provide you with some other insight.You probably can't go overboard in how hard you work to come up with answers to the challenges in this book. If you consult other books, work with a colleague, and write sample code to check out your solution, terrific! You will never regret investing your time and energy in learning how to apply design patterns.A danger lurks in the solutions that this book provides. If you flip to the solution immediately after reading a challenge, you will not gain much from this book. The solutions in this book can do you more harm than good if you don't first create your own solutions.The Organization of This BookThere are many ways to organize and 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. Interfaces Responsibility Construction Operations ExtensionsThese five categories account for five sections of this book. Each section begins with a chapter that discusses and presents challenges related to features built into Java. For example, the Interfaces section begins with a chapter on ordinary Java interfaces. This chapter will challenge your understanding of the Java interface construct, especially in comparison to abstract classes. The remaining chapters of the Interfaces section address patterns whose primary intent involves the definition of an interfacethe 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.Categorizing patterns by intent does not result in each pattern supporting just one type of intent. When a pattern supports more than one type of intent, it appears as a full chapter in the first section to which it applies, and gets a brief mention in subsequent sections. Figure 1.2 shows the categorization behind the organization of this book.Figure 1.2: One way to categorize a pattern is by its intentthe most important aspect of any pattern. Intent Patterns with This Type of Intent Interfaces ADAPTER, FACADE, COMPOSITE, BRIDGE Responsibility SINGLETON, OBERSERVER, MEDIATOR, PROXY Construction BUILDER, FACTORY METHOD, ABSTRACT FACTORY, PROTOTYPE, MEMENTO