Designing for Change - I

Designing for Change

All the patterns are required when we need our design to be flexible enough to face a change with out major impact. The Object orientation itself is just another style of programming that came up to solve many issues of the software engineering especially in the post implementation phase. Some of the fundamental principles / benefits on which the OO paradigm rode on are Reusability, Scalability, Maintainability etc. These were the goals for which the OO priciples and concepts stand for. If a system developed with a programming language that provides OO constructs does not provide the above said benefits, then it is not to be called a OO system.

The fact that you find programmers abundant in that language and you get the tools for that platform could have made it convenient to use it to build a system. But make sure if you really want to build a OO system or not before designing.

Some common design problems with design patterns that address the problem

• Creating an object by specifying a class explicitly
  
  

  Abstract factory, Factory Method, Prototype
  
  

• Dependance on specific operations
  
  

  Chain of Responsibility, Command
  
  

• Dependence on hardware and software platforms
  
  

  Abstract factory, Bridge
  
  

• Dependence on object representations or implementations
  
  

  Abstract factory, Bridge, Memento, Proxy
  
  

• Algorithmic dependencies
  
  

  Builder, Iterator, Strategy, Template Method, Visitor
  
  

• Tight Coupling
  
  

  Abstract factory, Bridge, Chain of Responsibility, Command, Facade, Mediator, Observer
  
  

• Extending functionality by subclassing
  
  

  Bridge, Chain of Responsibility, Composite, Decorator, Observer, Strategy
  
  

• Inability to alter classes conveniently
  
  

  Adapter, Decorator, Visitor

In this series we will take each problem one day and analyse how these patterns help solving them.

[ref : http://www.eli.sdsu.edu/courses/spring98/cs635/notes/patternIntro/patternIntro.html]