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.

       

1 comment:

Saurabh Singh said...

Dear Sanjeet, since you have been in B'lore for quite some time how about if you give me a call on some fateful day :-). I have lost all the numbers i had after I lost my HTC a week back. I guess this is the only way i can convey my message to you.

Saurabh Singh