2/23-2/25 - Design Pattern Flashcards
Alexander’s Pattern Language
- Each pattern describes a problem which occurs over and over again and then describes the core of the solution to that problem in way that you can reuse that solution multiple times.
- A pattern language is an organized way of tackling an architectural problem using patterns
Software Design Patterns
- Descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context
- They are not full designs or individual classes or libraries
- Design patterns name common successful ways of building software
Elements of a Design Pattern
- Pattern Name
- Problem Solved
- Solution
- Consequences
Example: A Text Editor
Problem: Document Structure • Primitive glyphs • Lines • Columns • Pages • Documents
Composites
- This is the composite pattern
- Applies to hierarchical structure
- Leaves and internal nodes have same functionality
- Composite implements the same interface as the contained elements
Pros of Composites
- Easy to add, remove new object types
* Clean interface, elegant code. No need to iterate over all object types to draw
Cons of Composites
- Have to fight to add corner cases
* Hard to enforce that a composite only has certain elements (Ex. A line does not contain columns)
Problem: Enhancing the User Interface
- We want to add borders, scrollbars, both
- How do we incorporate this into the physical structure?
- Object behavior can be extended using inheritance
Using Inheritance to Extend Object Behavior
- Major drawback: inheritance structure is static
- Subclass elements of Glyph: BorderedGlyph, ScrollGlyph, etc.
- Leads to a lot of classes
Decorators
- This is the decorator pattern
- A way of adding responsibilities to an object
- Problem: Supporting look and feel settings
Using Decorators to Add Responsibilities to an Object
- Decorations can be chosen dynamically
* Transparent enclosure
Problem: Supporting look and feel settings
• Different look and feel standards
Factories
- This is the factory pattern
- A class which abstracts the creation of objects. Different instances provide alternative implementations if that family
- “current” factory is still a global variable. Can be changed even at runtime
- Problem: Supporting multiple window systems
Problem: Supporting multiple window systems
- Big interfaces
- Different models of window operations
- Different functionality
Bridge Pattern
• This is the bridge pattern
• We have two hierarchies
• Logical – the view of our application, tuned to our needs
• Implementation – interface to the outside world; abstract base class with multiple
Implementations
- Logical implementation views can evolve independently as long as the bridge is maintained
- Problem: Spell checking
Logical Hierarchy (Bridge Pattern)
the view of our application, tuned to our needs
Implementation Hierarchy (Bridge Pattern)
- Interface to the outside world
* Abstract base class with multiple implementations
Problem: Spell checking (Bridge Pattern)
Solution: iterators
- Hide the structure of a container from clients
- Iterators work well if we don’t need to know the type of elements being iterated over
Visitor Pattern
- The visitor pattern is more general
- Iterators provide traversal of containers
- Visitors allow traversal and type-specific actions on container elements
- Separate traversal from action. Have a do-it method for each element type
- Extremely powerful pattern. Is non-obvious
- Whenever you have a hierarchical structure of heterogeneous elements write support for visitors. Other traversals can be written as a subclass of visitors
Strategy Pattern
- Strategy pattern isolates variations in algorithms
- Formatter is the strategy. Compositor is the context
- General principle: encapsulate variation
- i.e. Define abstract classes for things that are likely to change
Command Pattern
User essentially has a small programming language that is finite
- Abstraction makes this explicit
- Class structure can represent all possibilities explicitly
