Quick Reference

Note:

• The intention of this guide is to be succinct. Don't use this for extended explanation, just note brief points. People can follow links for explanation.
• While this guide may be useful for the exam, don't be exam specific. This is a concise list of concepts to jog your memory, not a Cheat Sheet with direct answers from last year or whatever.

Contradictory Design Maxims

• Design by contract and Tell, don't ask (arguably)
• Composite pattern and Avoid no-op overrides
• Eliminate irrelevant classes and No concrete base classes

Related Design Maxims

• Dependency inversion principle and Program to the interface not the implementation
• Avoid side effects and Command query separation and Keep accessors and mutators separate
• One key abstraction and Separation of concerns and Keep related data and behavior in one place
• Software reuse and Favor composition over inheritance and Reusable frameworks over reusable components

Performance-Focussed Maxims (as opposed to the usual design-focus)

• Flyweight
• Proxy
• Lazy Initialization

Design Pattern Cliff Notes

• Decorator
  • Identify by: Both HAS A and IS A at the same time, with multiple subclasses.
  • Used for: Adding flexible combinations of specialized functionality.
  • Classic Example: Adding scrolling functionality, borders, etc to a window.
  • Why better than alternatives: Avoids combinatorial explosion of subclasses.

• Composite
  • Identify by: Both HAS A and IS A at the same time, usually without subclasses.
  • Used for: Making many act as one.
  • Classic Example: Making a shape comprising other shapes.
  • Why better than alternatives: Can use singular and collective instances totally transparently (identically).

• Singleton
  • Identify by: Private constructor. Accompanying "public Whatever getWhatever" method, with that method containing lazy initialization of the return value.
  • Used for: Ensuring only a single instance is ever created.
  • Classic Example: Providing a single global Factory object or Settings object.
  • ** Why better than alternatives: No need to pass around many references. Prevents unwanted duplicates. Lazy initialization. Tidier than plain global variables,
  • Disadvantage: Hard to refactor, might indicate a design problem. See Beware singletons.

• Flyweight
  • Identify by: Factory class which returns objects from a pool of pre-existing instances, instead of creating a new instance every time.
  • Used for: Avoiding memory overhead of creating a multitude of identical objects.
  • Classic Example: Letter objects in a word processing application, tokens in State machine design
  • Why better than alternatives: Space saving (identical instances reference the same instance in memory)
  • Disadvantage: Because of the reference reuse, identity tests won't work as expected (eg Java object1==object2)

• Proxy
  • Identify by: Subclass with reference to sibling class. The subclass provides lazy initialization of the sibling class.
  • Used for: Creating an instance when you don't want to use that instance immediately. Can also be used to provide a reduced subset of the original object's interface.
  • Classic Example: Anything "on-demand". Diagramming program, creating instances of all components of the diagram when most are initially offscreen.
  • Why better than alternatives: Performance saving, as "grunt-work" is only carried out when actually needed. Can use proxy instances and real instances totally transparently.

• Adapter
  • Identify by: There are two variants.
    • Object-based adapters: A subclass that makes use of a toolkit/library class to implement its functionality
    • Class-based adapters: Multiple inheritance. A subclass inherits from one superclass in the usual way, and also inherits from another superclass to make use of that superclass's functionality
  • Used for: Making a useful-but-incompatible class work with an existing interface.
  • Classic Example: TextGraphics toolkit class allows you to render text, so is useful, but doesn't have the same interface as your existing graphical object class.
  • Why better than alternatives: Enables great reuse without modifying existing interfaces and code.

• Bridge
  • Identify by: Two hierarchies, one providing abstractions, the other providing implementations.
  • Used for: Decoupling interface from implementation so each can vary independently
  • Classic Example: Multiplatform GUIs, with a hierarchy of window types, each of which uses a subclassed hierarchy of drawing operations (with one subclass per platform)
  • Why better than alternatives: Avoids the multiplicity of subclasses (FancyWindowsWindow, BasicWindowsWindow, FancyMacWindow, BasicMacWindow, etc etc). Conforms to Dependency inversion principle.

• Builder
  • Identify by: Abstract-style superclass with an interface used to building individual components; implemented by subclasses. Related class which uses aforementioned abstract class to build objects transparently.
  • Used for: Build complex objects in a transparent way.
  • Classic Example: Text conversion. If an original document is stored as HTML, use a builder subclass for each type we need to convert to (ASCII, RTF, etc). Each subclass implements the abstract convertTagBlock() method. Converted document instance is retrieved from Builder object at the end.
  • Why better than alternatives: Allows fine external control over the building process while maintaining flexibility/extensibility/transparency.

• Interpreter
  • Identify by: An abstract syntax tree used for parsing.
  • Used for: Parsing.
  • Classic Example: Parsing.
  • Why better than alternatives: Intuitive, as each token is represented as an object.

• Command
  • Identify by: An abstract class to represent Commands/Actions
  • Used for: The OO equivalent of callbacks. Representing commands as objects allows commands to be transparently executed.
  • Classic Example: Menu Items. To assign functionality, simply add a Command object to a MenuItem object.
  • Why better than alternatives: Can make Composite commands from primitive commands. Total decoupling between triggering an action and the implementation of that action.