Quick Reference
From CSSEMediaWiki
(Difference between revisions)
RobertLechte (Talk | contribs) |
RobertLechte (Talk | contribs) |
||
| Line 11: | Line 11: | ||
* [[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 18: | Line 18: | ||
* [[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]] | * [[One key abstration]] and [[Separation of concerns]] and [[Keep related data and behavior in one place]] | ||
| − | + | * [[Favor composition over inheritance]] and [[Avoid inheritance for implementation]] | |
=== Performance-Focussed Maxims (as opposed to the usual design-focus) === | === Performance-Focussed Maxims (as opposed to the usual design-focus) === | ||
Revision as of 05:12, 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
- Favor composition over inheritance and Avoid inheritance for implementation
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.
- Identify by: There are two variants.
