Condividi tramite

Study Notes of "Pattern-Oriented Design"

  • Articolo

Here are the study notes of my recently attended training "Pattern-Oriented Design". The lecturer is Amir Kolsky.

  1. Six Do's
    1. Do the right thing  
      1. Process/PMs
    2. Do it right
      1. Understanding
    3. Do it efficiently
    4. Do it safely
    5. Do it predictably (in estimated time)
      1. The above three items is about design, which is developer's responsibility.
    6. Do it sustainably
      1. Manager
  2. Discussion: possible issues in a project
    1. External dependencies
      1. The dependencies change.
    2. Tight schedule
      1. Scope change
    3. Requirement change/add
    4. Quality problems
    5. Overly complex design
    6. Conclusion: most are caused by design change
  3. Discussion: the difference between procedural design and object oriented design
    1. Procedure consider two concepts: behavior (procedure) and data
    2. OO consider two concepts: entities and relationship, where each entity contains behavior and status (data).
  4. Three magic questions to know whether a design is good
    1. How can I test it? 
      1. The easier the better
    2. What do I need to know (if change it)?
      1. The less the better
    3. What do I need to do?
      1. The less the better
  5. Two questions to know whether an interface is good.
    1. Assertive or Inquisitive?
    2. Stable or Unstable?
  6. Most comments are not needed.  Here is the six kinds of comments and only the sixth is valuable.
    1. Not a comment.  
      1. e.g. author, time (version controller need to cover such information instead of comments)
    2. Useless  
      1. e.g. repeat the method name
    3. Fear  
      1. Comment the legacy code instead of deleting it.
    4. What
      1. Explain what the code do. The good method name should explain.
    5. How
      1. Explain how the code do. The clear code implementations should explain.
    6. Why
      1. Only this is valuable as the code cannot show it.
  7. Three steps to look into a design diagram
    1. Look for relationship
      1. Static: inheritance
      2. Dynamic: interface
    2. Abstract class: variation
    3. Interface
      1. Stable or unstable
  8. Three essential skills of a  developer
    1. Programming   =  Design    -> Implementation
    2. Design             = Problem -> Design
    3. Refactor          = Design    -> Another Design
  9. The "Constants.cs"  file is a bad thing
    1. It has poor cohesion.
      1. Break the second magic question: need to know the whole design of the system if need to change the file.
  10. Criterions to measure code quality
    1. Clarity  
      1. Good names. No need to explain code with comments.
    2. No Redundancy
      1. Redundancy: A change to one thing would necessitate a similar change to all the redundant ones.
    3. Strong Cohesion
      1. "One Responsibility in One Place"
    4. Intentional Coupling
      1. The technical nature of the relationship between two entities.
      2. Good coupling: intentional. Vs. Bad coupling: accidental.
      3. Encapsulation aims to improve coupling and cohesion   
        1. Hidden things cannot be coupled to. 
        2. Cohesive issues are easier to hide.
        3. Need a balance between encapsulation and redundancy.
    5. Focus
      1. The locality of responsibility.
      2. Need a balance between focus and cohesion.
  11. Context of a design:

 

Now

Future

Requirement
    •  
  • Functionality  
  • Non-Functionality    
    • Performance    
    • Usability    
    • Security  

Pay 100% work
    •    
  • Scalability
  • Extensibility   
  • Reuse
      •   
    •   

Pay 100% work

Developer
    •   
      •    
  • Maintainability
      •     

Pay 100% work
    •   
      •    
  • Reuse
  • Extensibility
      •     

Pay 0% work (just need simple refactor if they become required,

as the code is well maintainable)
  1. There are two separated aspects to design a system. Never mixing the two aspects when doing design.
    1. How the system runs?
      1. Design the interface/relationship between objects.
    2. How to construct the system?
      1. Factory is responsible for construction.
  2. Design is about the problem, not the implementation.
  3. Advice from the Gang of Four
    1. Design to interfaces
    2. Favor object delegation over class inheritance
    3. Consider what should be variable in your design … and "encapsulate the concept that varies"
  4. The Strategy Pattern
    1. We need a different behavior (variation) at different times (dynamic) for different clients (reuse) requesting the service.
    2. GoF Intent: Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
  5. Commonality-Variability Analysis
    1. Commonality analysis is the search for common elements that helps us understand how family members are the same.
    2. Those things that are found by commonality analysis can often become the abstract types.
  6. The Template Method Pattern
    1. GoF Intent: Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.
    2. E.g. Commonality: the steps of several algorithms. Variation: each specific algorithm
  7. The Bridge Pattern
    1. GoF Intent: De-couple an abstraction from its implementation so that the two can vary independently.
  8. The Adapter Pattern
    1. We need to change the interface of a class that has the right stuff but has the wrong interface.
    2. GoF Intent: Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.
  9. The Façade
    1. We want to use a subset of the functionality of a complex system, or to simplify its interface, or to improve how it is used, or to provide OO access to a non-OO system.
    2. GoF Intent: Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use.
  10. The Analysis Matrix
    1. Motivation: Information overload:
      1. More information than you need.
      2. No good way to organize it.
      3. No way to tell what is important.
      4. No way to see what the cases are.
    2. Each column represents a given case, Each row is used to represent the concept that case is an example of. Build the matrix as we go.
  11. The Abstract Factory
    1. We need to create families of objects for particular situations. That is, particular clients need particular sets of instantiations.
    2. GoF Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
  12. The Singleton Pattern
    1. GoF Intent: Ensure a class only has one instance, and provide a global point of access to it.
  13. The Family of Proxy Patterns
    1. We need to add functionality before or after accessing an object in such a way that the client object doesn't know it is talking to a different object.
    2. GoF Intent: Provide a surrogate or placeholder for another object to control access to it.
    3. Different kinds of proxy patterns
      1. The Protection  Proxy Pattern
      2. The Cache Proxy Pattern
      3. The Virtual Proxy Pattern
      4. The Remote Proxy Pattern
  14. The Decorator Pattern
    1. GoF Intent: Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to sub-classing for extending functionality.
    2. A common example of decorator pattern is the Streaming IO: FileStream, MemoryStream, CompressionStream…
  15. Chain of Responsibility
    1. Have a set of objects that can perform a task but the requester of the task does not want to know which one actually does it.