Design Toolbox

Here's a quick summary of Design Guidelines for your Design Toolbox.

Object Oriented Basics

  • Abstraction
  • Encapsulation
  • Polymorphism
  • Inheritance

           

Object Oriented Principals

  • Encapsulate what varies (think strategy pattern)
  • Favor composition over inheritance
  • Program to interfaces not implementations

           

Object Oriented Patterns

  • Strategy – Defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm very independently form clients that use it.
  • Observer – Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
  • Decorator – Attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to sublcassing for extending functionality.
  • Factory Method Pattern – Defines an interface for creating an object, but lets subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses. Creates objects through inheritance.
  • Abstract Factory Pattern – Provides an interface for creating families of related or dependent objects without specifying their concrete classes. Creates objects through composition.

           

General Design Principals

  • Identify the aspects of your application that very and separate them from what stays the same.
  • Program to an interface, not an implementation.
  • Favor composition over inheritance.
  • Strive for loosely coupled designs between objects.
  • Classes should be open for extension, but closed for modification.
  • Depend on abstractions. Do not depend upon concrete classes.
  • Follow the Dependency Inversion Principle Guidelines
    • No variable should hold a reference to a concrete class.
      • If you use new, you'll be holding a reference to a concrete class, use factories.
    • No class should derive from a concrete class.
      • If you derive from a concrete class, you're depending on a concrete class, derive from abstractions.
    • No method should override an implemented method of any of its base classes.
      • If you override an implemented method, then your basee class wasn't really an abstraction to start with. Methods defined in your base class were meant to be shared by all subclasses.

     

     

Add Comment Filed Under [ Design Patterns ]

Comments

No comments posted yet.

Leave Your Comment

Title*
Name*
Email (never displayed)
 (will show your gravatar)
Url
Comment*

Please add 4 and 2 and type the answer here:

Preview Your Comment.