Quick Reference
From CSSEMediaWiki
(Difference between revisions)
RobertLechte (Talk | contribs) |
|||
| Line 8: | Line 8: | ||
=== Contradictory Design Maxims === | === Contradictory Design Maxims === | ||
| − | * [[Design by contract]] and [[Tell, don't ask]] | + | * [[Design by contract]] and [[Tell, don't ask]] (arguably) |
* [[Composite]] pattern and [[Avoid no-op overrides]] | * [[Composite]] pattern and [[Avoid no-op overrides]] | ||
* [[Eliminate irrelevant classes]] and [[No concrete base classes]] | * [[Eliminate irrelevant classes]] and [[No concrete base classes]] | ||
| + | * | ||
=== Related Design Maxims === | === Related Design Maxims === | ||
| Line 16: | Line 17: | ||
* [[Dependency inversion principle]] and [[Program to the interface not the implementation]] | * [[Dependency inversion principle]] and [[Program to the interface not the implementation]] | ||
* [[Avoid side effects]] and [[Command query separation]] and [[Keep accessors and mutators separate]] | * [[Avoid side effects]] and [[Command query separation]] and [[Keep accessors and mutators separate]] | ||
| + | * [[One key abstration]] and [[Separation of concerns]] and [[Keep related data and behavior in one place]] | ||
| + | |||
| + | |||
| + | === Performance-Focussed Maxims (as opposed to the usual design-focus) === | ||
| + | * [[Flyweight]] | ||
| + | * [[Proxy]] | ||
| + | * [[Use lazy initialization pattern|Lazy Initialization]] | ||
| + | |||
| + | |||
=== Design Pattern Cliff Notes === | === Design Pattern Cliff Notes === | ||
| Line 24: | Line 34: | ||
** Classic Example: Adding scrolling functionality, borders, etc to a window. | ** Classic Example: Adding scrolling functionality, borders, etc to a window. | ||
** Why better than alternatives: Avoids combinatorial explosion of subclasses. | ** Why better than alternatives: Avoids combinatorial explosion of subclasses. | ||
| + | |||
* [[Composite]] | * [[Composite]] | ||
| Line 30: | Line 41: | ||
** Classic Example: Making a shape comprising other shapes. | ** Classic Example: Making a shape comprising other shapes. | ||
** Why better than alternatives: Can use singular and collective instances totally transparently (identically). | ** 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 [[Use lazy initialization pattern|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. | ||
Revision as of 04:59, 5 October 2008
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
- 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 abstration and Separation of concerns and Keep related data and behavior in one place
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.
