« Getting caught up on archived posts
Latest post
Treo 700w Smart Phone »

The Foundation of Design Patterns

Thursday, January 12, 2006 12:00:00 AM (Central Standard Time, UTC-06:00)
Since the popularity of design patterns in the mid to late 90's I have bounced back and forth between learning them and just being aware of them.  I bought a Java based book (Head First Design Patterns) on a recommendation of a friend (Ed Ferron) of mine last summer.  
 
I spent the next couple of weeks perusing through it.  One thing that dawned on me was that all design patterns have the core principals that many of us use everyday (or should use) to design and write software.  Forget the names for right now… all of these named/referenced patterns are based on core principals.  Many of these concepts have become engrained in how we do stuff.  The founders of design patterns combine these principals to solve common problems, and then give them names for reference.  These principals are identified in different ways through out the book, but really aren't compiled into one area.  The compilation of these principals is as follows:

Use Abstraction 
  • Identify the aspects of your application that vary and separate them from what stays the same.
 
Interfaces
  • Program to an interface not an implementation.
 
Favor Composition Over Inheritance
  • Encapsulate a family of algorithms into their own set of classes.
    1. Allows you set behavior at run-time as long you program to an interface.
 
Dependency Inversion
  • Depend upon Abstractions. Do not depend upon concrete classes.
  • High Level Components should not depend on low level components, rather they should depend on abstractions.
 
Guidelines for following principle:
    1. No variable should hold a reference to the concrete class.
    2. No class should derive from a concrete class (derive from an interface or abstract class).
    3. No method should override an implemented method of any of its base classes.  If you override, then your base class wasn't really an abstraction to begin with.  These methods are meant to be shared with your subclasses
       
Open/Closed Principles
  • Classes should be open for extension and closed for modification.
    1. Altering existing code that has been tested and is virtually bug free can be expensive.

Principle of Least Knowledge
  • When designing a class, be careful of the number of classes it interacts with.  There are a number of problems that arise if you are not careful.
    1. Creates heavy coupling among the implementation.
    2. Many dependencies create a fragile system that will be costly to maintain and complex for others to understand.
         
Guidelines for following principle:
  1. Only invoke methods on:
    • the object itself.
    • an object passed in as a parameter to the method.
    • any object the method creates or instantiates.
    • any components of the object.
       
Circular Dependencies   
  • Dependency rot happens when you have high-level components, depending on low-level components, depending on high-level components.
 
Guidelines for following principle:
  1. Low level components never call high level components.
  2. High level components determine when low level components are needed.          
     
Single Responsibility Principle
  • Classes should have only one reason to change.
  • Assign each responsibility to one and only one class.
 
Guidelines for following principle:
Classes that adhere to the principle tend to have high cohesion and are more maintainable then classes that take on multiple responsibilities.
 
High Cohesion --> a class designed around a set of related functions.
Low Cohesion --> a class designed around unrelated functions.
 
My point is… maybe I don't really have to memorize all of them… I can continue to just look them up when they come up in design reviews.  The key is to understanding the underlying principles they are based on and how those principles are accomplished.
     

Posted in  |Comments [0]     

Comments are closed.