Design Patterns Based on Design Patterns. Elements of Reusable Object-Oriented Software. by E.Gamma, R. Helm, R. Johnson,J. Vlissides

Adapter Synopsis: Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces. Context: You want to use an existing class whose interface does not match the one you need.

Adapter: motivating example Example: A Drawing Editor that operates with various Shapes:(Line and TextShape). Interface (set of services) to each subclass of Shape is predefined. Would like to use an off-the-shelf implementation, TextView, for dealing with the text, but TextView uses a different interface, and thus, cannot be used in a straightforward way. Solution: Define TextShape so that it adapts TextView 1. Class Adapter: TextShape inherits interface from Shape and inherits implementation from TextView 2. Object Adapter: TextShape includes a TextView Object. Each service of TextShape is implemented using the appropriate service of TextView.

Object Adapter Off-the-shelf implementation. Source code is unavailable Original design specifies the interface to all Shapes

Object Adapter Compose the existing object (the Adaptee) within an Adaptor object that implements the desired interface. The Adapter forwards to the subject while possibly performing additional actions.

Another Solution: Class Adapter Adapter inherits the interface from the Target and the implementation from Adaptee

Strategy Synopsis: Define a family of algorithms, encapsulate each one and make them interchangeable. Strategy lets the algorithm vary independently from clients that use them. Context: Need to provide a way of configuring a class with one of many behaviors, or Need different versions of an algorithm, for example, for different time/memory constraints, or Need to hide a lot of complex algorithm-specific implementation details

Strategy Abstract class, declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy Each ConcreteStrategy implements the algorithm using the Strategy interface

Strategy: example Need to implement different strategies for a character in a game scenario, depending on difficulty level. Context - TetrisBoard Abstract class - BlockDropStrategy Concrete classes - DropStrategyLevel-1… DropStrategyLevel-N

Abstract Factory Synopsis: provide an interface for creating families of related or dependent objects without specifying their concrete classes. Motivating example: Consider a user interface toolkit that supports multiple look-and-feel standards Requires portability across different look-and-feel standards, different widgets (buttons, scroll bars, etc.) should not be hard coded for a particular look-and-feel.

Abstract Factory Solution: abstract WidgetFactory class, defines interface for creating each kind of widget, abstract class for each kind of widget, with concrete classes implementing different look-and-feel standards

Abstract Factory for Widgets Notation: AB means A creates (instantiates) B

Abstract Factory Declares an interface for creating product objects Implement creation concrete products for each “version” Declare interface for product Implement concrete product

Abstract Factory Hides the knowledge of which concrete classes are used Hides how instances are created and put together All the system knows - is the interfaces of abstract classes This provides a lot of flexibility and make the system “configurable” at either compilation or run time.

Abstract Factory: Applicability Use when a system should be independent of how its components are created a system must be configured with one of multiple families of products a family of related products are designed to work together and you need to enforce that you want to provide a class library of products, and you want to reveal just their interfaces, not implementation

Maze Problem Context: build a maze for a game. Maze is a set of rooms. Each room knows 4 neighbors Neighbor is a door, a wall or another room To create a maze - must create a set of rooms

Maze Extend the design to be able to create an enchanted maze as well as the regular maze. Enchanted maze may have enchanted rooms -- rooms which have magic keys inside doors that can be opened only with a magic key in addition to regular rooms,doors and walls.

Maze, continued... Hardcoding the layout of the maze in the maze constructor is inflexible - need a separate constructor for every configuration. Builder pattern allows to construct a maze based on a given configuration.