Design Patterns in Java Made Simple

Identifies the need for the Decorator pattern by identifying problems in the design which is lacking it.

Attempts to solve the problem by subclassing. This attempt will eventually fail.

Demonstrates a programming bug that can be materialized and manifested when subclassing is used to implement a decorator.

Introduces decorators based on object composition rather than inheritance.

Summarizes this module.

Explains the need for the adapters and how they differ from decorators.

Applies the Adapter design pattern to resolve the problem identified in the initial design.

Demonstrates common problems which appear when programmers start relying on adapters beyond reasonable bounds.

Splits the adapter into smaller, interacting objects to resolve the issues appearing in the bloated, heavyweight adapter.

Summarizes this module.

Outlines problems that appear when domain-related behavior is implemented as a fixed block of code.

Demonstrates how basic implementation of the Strategy design pattern helps introduce flexibility in behavior.

Demonstrates how interface can be used to represent a Strategy.

Demonstrates how strategies can be made even more flexible without complicating the consumer.

Outlines full power of dynamically injected strategies.

Introduces recursive nature of strategies by introducing strategies that depend on their own strategies.

Summarizes this module.

Introduces the problem domain where runtime types of objects used sometimes need to vary. Introduces Abstract Factory as the solution to varying types of consumed objects.

Outlines principal limitation of the Abstract Factory: Inability to reconcile constructor parameter lists in unrelated product bundles.

Demonstrates possible solutions to the problem of constructor parameter lists through use of common, extensible document types.

Demonstrates effective implementation of concrete factories when their common interfaces have been designed.

Completes the previous demonstration by implementing all the details in concrete factories.

Demonstrates the use and substitutability of concrete factories. Outlines pros and cons of applying the Abstract Factory pattern.

Summarizes this module.

Explains how large Abstract Factory can be transformed into smaller, more focused mini-factories: factory methods.

Explains how state can be retained behind the factory method, so that it doesn't have to be passed with every call to the method.

Introduces parameter fixing, so that the factory method can be consumed without knowing all the parameters.

Demonstrates the principal power of factory methods to stop propagation of design changes that are affecting their products, but not their consumers.

Introduces the functional concept of currying to factory methods, demonstrating how factory methods can be simplified and made more powerful.

Summarizes this module.

Identifies principal limitations characteristic to all factories: inability to handle optional components and components that appear in multiple forms.

Introduces the Builder design pattern as an alternative to factories.

Explains common methods of validating components passed to the Builder. Introduces the fail-fast principle.

Explains how Builder can cope with components that appear in multiple forms, and with optional components.

Demonstrates how a fully populated Builder can be reduced to a Factory Method without making it visible to the client.

Summarizes this module.

Introduces a new example domain: Building a large graph of objects. Explains how Builder pattern can apply to this problem.

Outlines the principal problem with the Builder pattern: Inconsistency of the Builder object through its lifetime. Explains why we need the Builder object to be internally consistent despite missing components.

Introduces a completely new design of the Builder, which only exposes parts of the builder object that are guaranteed to be consistent.

Extends previous design by supporting alternative representations of some components in the consistent builder.

Demonstrates fluent API applied to the Builder design pattern. Helps consumer retain full readability and safety when consuming a builder.

Explains complexities and solutions to the problem of designing an immutable builder in software which insists on immutability.

Demonstrates how use of immutable collections can help design an immutable builder almost with no effort.

Summarizes this module.

Outlines how complexity of a class grows when it attempts to handle multiple contained objects.

Introduces basic implementation of the Composite design pattern. Demonstrates its immediate simplifying effect on the class that consumes it.

Demonstrates that composite elements are recursive by definition. Explains how this recursive nature can be limited, depending on the problem domain to which it is applied.

Demonstrates how Composite pattern can be hidden behind a Factory Method, so that the client only remains dependent on an abstraction, not on concrete types used to implement the Composite pattern.

Introduces more variation into the Composite pattern by combining it with full-fledged Abstract Factory pattern.

Experiments with the thought that some consumers have an opposite need: To view all occurrences as multiple objects, including to represent one object as many.

Summarizes this module.