Thursday, November 3, 2011

Design Pattern : behavioural

  1. Chain of responsibility
    1. The purpose for this is for high cohesion. This means, to increase the reusability.
    2. This can be visualized with the specialization in manufacturing world. Each function performs specialized task, and chained together to perform a bigger task.
    3. These functions can be reused in other scope since they are doing specialized and simpler task.
  2. Command
    1. This is to encapsulate requests.
    2. Thus, for a program to call any command, it has the similar interface.
  3. Interpreter
    1. This will translate the context passed by client and perform necessary task on it.
  4. Iterator
    1. This to enable to parse through the whole data structure.
  5. Mediator
    1. As a middle man between 2 sub-program to enable low coupling, or for decoupling purpose.
  6. Momento
    1. This is to capture the state of the class and stored in another object
    2. Good for undo to restore the object to its previous state
  7. Observer
    1. It’s for event driven.
    2. As listener, or “don’t call me, I’ll call you”
    3.  (After reading the online notes, I am not convinced by what was told in the class, so, please see d)
    4. objects need to be registered, the changes will be applied to all objects
  8. State
    1. This is to allow control on the behavior of the object when its internal state changes.
  9. Strategy
    1. Similar to state, but in different context.
    2. Different algorithms are implemented in child classes.
  10. Template method
    1. Preparing the abstraction/skeleton of the classes in the base class.
  11. Visitor
    1. To improve for high cohesion
    2. Slightly similar to Mediator, but mediator create the element class, while visitor does not. The element is created by client, and visitor is accepted by client to perform operation on element.
  12. Null object method
    1. This is used to handle “null object”. This null object is a real object, while it will not be set or do nothing when it is called.

Design Pattern : structural

  1. Composite
    1. It looks like tree structure, the end node is called leaf.
    2. All the node has uniform interface, thus they can be used/called via uniform operation/data structure
  2. Adaptor
    1. This is using another class to encapsulate the class to be accessed. Thus the caller will see/use the same interface regardless on how the class to be assessed being implemented.
  3. proxy
    1. This is acting as a middle man to handle the client requests and sever response.
  4. Façade
    1. This is using an interface to reduce the complexity.
    2. It packages the objects and methods
  5. Decorator
    1. This is for dynamically to add new responsibility / variation on the methods
    2. It will hold the base class pointer, and the real implementation on the child class or actual object.
  6. Bridge
    1. This is acting like multi-purpose adapter.
    2. It serves for multi-platform.
  7. Flyweight
    1. It handles the pool of resources that are shared by the clients.
  8. Private Class Data
    1. This is to put the private and readonly data into a class, and being initialized by construtor.

Design Pattern : creation

  1. Singleton
    1. this is basically suitable for single instance through out the program.
    2. it can contains the static variables used by the program.
    3. the benefits for this versus global variable is for data encapsulation purpose. You can have accessor and modifier functions as a guarding to set or read the variable.
  2. Factory
    1. The factory is a class to hold and control the creation of the class objects.
    2. The object class held by factory is the base class, thus any of the child class object can be instantiated, and transparent in the main program.
  3. Abstract Factory
    1. Similar to Factory type, but the factory is an abstract class.
    2. This is good for multi-platform support, where the right factory will be instantiated based on the platform.
  4. Builder
    1. This is to hide the complexity of the object by the builder.
    2. The program can have multiple builder with same operation but different methods.
    3. There is a “directory” to call the right builder to call for operation to produce “product”.
  5. Prototype
    1. Using abstract class to force the functions overidding (enforcement on the child classes)
    2. Thus the child classes need to have the implementation for the functions specified by the base class (the prototype abstract class)

OO concept and software development practices

I attended a 5-day Design Pattern class last year, and the summary that I published then, was the initial thought of this k-db site. I am revising them and put them here. :)

Day 1 : OO concept and software development practices

  1. OO concept revised.
      • Normally these are discussed :
        1. inheritance
        2. composition
        3. encapsulation
        4. polymorphism
      • Discussed in class :
        1. abstraction
        2. encapsulation
        3. generalization
        4. specialization
  2. Type of errors
      • compilation
        1. syntax
        2. contextual
      • linking
      • runtime
      • logical
  3. Example to show the best way to code to avoid error :
      1. if (x == 0)
      2. if (0 == x) <– using this coding style, missing a "=" in the condition statement will alarm error during compilation.
  4. Why it is a good practice to use static for variable declaration?
      1. for information hiding.
      2. so people won’t use extern to access to it in other file, to ensure the value is not overwritten by unknown.
      3. error prone during linking.
  5. Software quality measurement :
      1. reusability : code, function, user experience (dialogue box/interface), software pattern can be used in more context
      2. standardization
      3. robustness
      4. time to market
      5. stability
  6. Memory problem :
      1. memory leaks –> needs to take care by programmer
      2. memory fragmentation –> this will be based on how the heap memory is used and allocated for dynamic objects
  7. Good programming practice to have these 2 behaviour
      • low coupling
        • less dependency
      • high cohesion
        • make it smaller functions thus high reusability.
  8. Single assignment of responsibility
      • design by contract
        1. pre condition : should be caller’s responsibility, so callee need not to check and throw exception.
        2. post condition : should be callee’s responsibility, so caller can assume the result return is OK


As an introduction to design pattern in software, there are 3 categories : creation, behavioural and structural. These will be in the next few posts.