Wednesday, 2 September 2009

Design Principles

A Design principle is a basic tool or technique that can be applied to designing or writing code to make it more maintainable, flexible or extensible.

Some of the design principles are:
  • Encapsulate what varies
  • Code to an interface rather than to an implementation
  • Each class in your application should have only one reason for change
  • Classes are about behavior and functionality
  • Classes should be open for extension and closed for modification - Open Closed Principle
    • It features Inheritance, and composition
    • It exhibits abstraction and encapsulation in action
  • Avoid duplicate code by abstracting out things that are common and placing those things in a single location - Don't repeat yourself
    • It's really about one requirement at one place
    • It's not only about removing duplication; it's also about making good decisions about how to break up your systems functionality.
  • Every object in your system should have a single responsibility and all its services should be focused on carrying out that single responsibility - The Single Responsibility Principle (SRP)
    • Using this principle doesn't essentially make your classes smaller; it makes them larger instead, as all services exposed by the class remains at one point. Also, it will enable you to create fewer classes which mean better maintenance.
    • Cohesion is the other name for this principle, if you are writing a highly cohesive class it means that this principle is correctly implemented.
  • Subtypes must be substitutable for their base types - The Liskov Substitution Principle (LSP)
    • The LSP is all about well designed inheritance. When you inherit from your base class you must be able to substitute your subclass for that base class without things going terribly wrong. If it does, then you must have used inheritance incorrectly.
    • Violating LSP makes the code confusing. It's hard to understand code that uses inheritance incorrectly.
    • Delegation comes to rescue in such circumstances - Delegation is when you hand over the responsibility for a particular task to another class or method.
      • If you need to use functionality in another class, but you don't want to change that functionality, consider using delegation over inheritance.
    • Composition
      • An alternative to
        inheritance just as delegation.
      • In composition, your object completely owns the composed objects, and they do not exist outside of their usage in your object.
      • E.g. a text file and its contents. If you delete the text file all its contents are gone!
    • Aggregation
      • Another alternative to inheritance.
      • In aggregation, you use another object inside your object. Both can exist outside of each other.
      • e.g. if you copy a file inside a folder, the file(s) and the folder continue to exist, even if you delete the folder, the file that's outside the folder will remain as it is.
    • If you favor delegation, composition, and aggregation over inheritance, your software will be more flexible, easier to maintain, extend and reuse.

       

Design Patterns Quick View

    There are 3 types of design patterns

  1. Creational

    These are the ones that take care of creating new objects. Sometimes creating objects simply with new can complicate the design of the software. To handle such unique situations the following patterns are used.

    Abstract Factory Pattern

    clip_image001[6]

    Factory Pattern

    clip_image002[6]

    Builder Pattern

    clip_image003[6]

    Prototype Pattern

    clip_image004[6]

    Singleton Pattern

    clip_image005[6]

  2. Behavioral

    These patterns identify common communication patterns between objects. They aim to increase the flexibility in carrying out the communication. Such patterns are listed below:

    Observer Pattern

    clip_image006[6]

    Strategy Pattern

    clip_image007[6]

    Command Pattern

    clip_image008[6]

    Iterator Pattern

    clip_image009[6]

    State Pattern

    clip_image010[6]

  3. Structural

These are design patterns that ease the design by identifying a simple way to realize relationships between entities.

Decorator Pattern

clip_image001[8]

Adapter Pattern

clip_image002[8]

Fa├žade Pattern

clip_image003[8]

Bridge Pattern

clip_image004[8]

Proxy Pattern

clip_image005[8]