Skip to main content

SOLID- Design Principles



The SOLID Principles of programming are a set of rules which when followed during designing and developing an object oriented application, will reap the following benefits.
  • Loosely Coupled Application
  •  Easily Extensible application
  • Highly manageable code for maintenance

SOLID is an acronym that can be expanded as Below:
(I’ll first  get into theoretical aspect of it and then clarify it via code)


S: Single Responsibility Principle 
A class should do only one thing .
Logically speaking Separation of Concern and separation of responsibility is what we need to differentiate. This principle talks about responsibility not concern.

“My responsibility as a developer is to meet deadline and code as per the standards, if the client is not happy, that is none of my concerns (isn't it soothing…..)”

.Same goes with class, it should be doing only one thing at a time, if multiple responsibilities are entrusted to it(imagine you doing job of a co-coordinator, developer, designer, team leader all at one time…all you’ll become is jack of All, master of None).

In simpler terms, always make sure a class has ONE and ONLY ONE responsibility(it does not mean it should have only one functions though.)

O: Open / Closed Principle 
 A class should be open for extension but closed for modification. Classes should be designed so they can be inherited from without having to modify them.
While designing classes for any enterprise application, always keep in mind that the class should not be modified, however whenever there is a need, create another class and extend the base class.

L:Liskov Substitution Principle 
 Derived classes must be substitutable for their base class.
 When a class method accepts an object, the method should be able to accept children of that object.
If there is Base Class A and an inherited class B, wherever an object of A is expected and we instead pass an object of B, the code should work fine.(Simple OOPS right??...obviously the first thing that strikes the mind is Interfaces, don’t worry it’s next).

I:Interface Segregation Principle 
 Interfaces should be fine grained and only provide for current project needs. When building interfaces, never add more functionality than what is needed at the time.
Assume creating an Interface IMylife(that will sum up the gist of life.).Now let’s add some methods to it
Void childhoodmemories ();
Void MylifeAsTeenager();
Void MyYouth()
Void MyRetirement();
Void MyDeath()
Void MyNextLife()
Void MyNExtLifeChildhood()

Now let’s try to implement this interface, you’ll endup implementing your nextbirth(and all you wanted was implement your current).
In the current scenario, you’ll definitely throw not implemented exception in all the cases that does not hold true currently.
So the point is, just do the needful, planning next life is not such a good idea in the current life(am I getting boring..or too sarcastic?)

D: Dependency Inversion Principle 
High level modules should not depend on low level modules, but instead both should depend on abstractions. Interfaces should be used as placeholders and factory classes should be used to instantiate objects. This causes loose coupling between classes.

OOPs does it sound like Substitution principle?...well these principles does not work in isolation, they are used collectively to achieve the goals of designing.

I’ll start a series now to implement these principles in code starting form SOLID-Single Responsibility Principle.

Hope the information is useful,

Do remember to go to my next blog entry in this series.

Till next we connect…….
Happy Learning…..
Labels:

Comments

Post a Comment

Popular posts from this blog

Asp.Net 4.0: An Overview-Part-III

This is the last post in the series which will explore the following new features of ASP.Net 4.0  Performance Monitoring for Individual Applications in a Single Worker Process Web.config File Refactoring Permanently Redirecting a Page Expanding the Range of Allowable URLs Performance Monitoring for Individual Applications in a Single Worker Process It is a common practice to host multiple ASP.NET applications in a single worker process, In order to increase the number of Web sites that can be hosted on a single server. This practice results in difficulties for server administrators to identify an individual application that is experiencing problems. ASP.NET 4 introduces new resource-monitoring functionality introduced by the CLR. To enable this functionality, following XML configuration snippet is added to the aspnet.config configuration file.(This file is located in the directory where the .NET Framework is installed ) <?xml version="1.0" encoding="UTF-8...
Post a Comment
Read more

WCF-REST Services-Part-II

HOW REST is implemented in WCF Part-I of the series explored the REST conceptually and this post will explore how REST is implemented in WCF. For REST implementation in WCF, 2 new attributes namely WebGetAttribute and WebInvokeAttribute are introduced in WCF along with a URI template mechanism that enables you to declare the URI and verb to which each method is going to respond. The infrastructure comes in the form of a binding ( WebHttpBinding ) and a behavior ( WebHttpBehavior ) that provide the correct networking stack for using REST. Also, there is some hosting infrastructure help from a custom Service¬Host ( WebServiceHost ) and a ServiceHostFactory ( WebServiceHostFactory ). How WCF Routes messages WCF routes network messages to methods on instances of the classes defined as implementations of the service. Default behavior ( Dispatching ) for WCF is to do this routing based on the concept of action. For this dispatching to work, an action needs to be present in ev...
Post a Comment
Read more

WPF Routing

WPF (3.5) introduced the concept of Routing that made the event routing easies in the scenarios where it was tedious to handle events. Consider a scenario where there are a number of Hyperlinks in a Panel that direct to separate locations on Click. Now if this is done in normal programming, each hyperlink will have to have code for execution. It would be easier and cleaner if we could handle the hyperlinks in the container (the Panel) that handles the click and redirects to appropriate location. WPF handles the events with the following 3 strategies. Direct events are like ordinary .NET events. They originate in one element and don’t pass to any other. For example, MouseEnter is a direct event. Bubbling events are events that travel up the containment hierarchy. For example, MouseDown is a bubbling event. It is raised first by the element that is clicked. Next, it is raised by that element’s parent, and then by that element’s parent, and so on, until WPF reaches the top of the e...
Post a Comment
Read more