Quick Reference

From CSSEMediaWiki
Revision as of 06:34, 5 October 2008 by RobertLechte (Talk | contribs)
Jump to: navigation, search

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.


Contents

Contradictory Design Maxims


Related Design Maxims


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


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.


Coming soon: Builder, Interpreter, Command

Personal tools