ICS 121: Design patterns

Patterns are written descriptions of well-known solutions to common design problems.
Patterns are a form of reuse: if one person writes it down, many people can use the same ideas in their own designs.
Contents of a design pattern:
- Name
- Problem/Motivation, Context/Applicability/Forces
- Solution, Consequences, Examples

Reading patterns gives you some understanding of the problems that other designers have commonly faced, the trade-offs involved and how they have solved them.
Using patterns in your designs will make them more understandable to other designers who have read the same patterns.
Using patterns in your design can reduce the amount of needed design documentation.
Learning popular design patterns will help you understand what other designers say, and how other systems are designed. E.g., swing uses the observer/observable pattern.

Problem: you would like to be able to allow objects to nest. E.g., groups of shapes in a drawing tool, panels and widgets in a GUI, or files and directories on a disk.
Forces: Client code should be made simple. You plan to add new types of simple objects later.
Solution: the group is a subclass of an abstract element; the group contains multiple elements
UML diagram

Problem: one object must update itself whenever another certain object changes
Forces: the other object should not be complicated by code that explicitly sends notifications
Solution: The Subject/Observable object inherits from a superclass that maintains a list of observers. When the Subject/Observable changes state, it just calls one method. The Observer implements an update() method that is called when the Subject/Observable changes state.
UML diagram

Problem: An object sometimes has an extra feature added to it, but not always. E.g., a button can have one of many border styles, but it usually has none.
Forces: client code should not know how this feature is added in. The main object should not know about that feature. Many possibilities add-on features are planned.
Solution: implement a Decorator object that intercepts messages to the main object and processes them. Most messages are passed on to the main object, but messages related to that feature are handled by the Decorator.
UML diagram

Problem: One object has multiple potential algorithms for one operation. E.g., use different sorting algorithms depending on the size of the data or how well sorted it is already.
Forces: There are many algorithms and we plan to add more later. We do not want to modify the object itself every time we add a new algorithm. The best algorithm to use can only be determined at run-time and may change over time.
Solution: place each algorithm in a Strategy object and have the main object reference the Strategy object. To change algorithms, replace the Strategy object with another one.
UML diagram

Problem: one class would like to make instances of many "product" classes at run-time. E.g., each a tool bar button in a drawing tool has an icon and creates instances of some subclass of Shape.
Forces: There are many types of "products" and we plan to add more. We do not want to modify the client code every time we add new type of product. The product produced may vary at run-time.
Solution: Do not use "new Circle()". Instead, use a class called an Abstract Factory as a strategy for creating shapes. The abstract factory has subclasses that are concrete factories for each type of product.
UML diagram