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

Authentication using Social Networking portals(Facebook, Gmail, and Yahoo)

There are tons of sites, which offer sign on using the social networking site credentials (Facebook, gtalk, twitter and the list continues).It can be termed a “SINGLE SIGNON” and offers a lot of benefits compared to traditional database authentication approach. However, not storing user credentials in the DB imposes an additional risk. How to track who all logged into the system. Now the question is, which approach to follow. The best approach is to use inbuilt asp.net users for storing the logging info about user activities and using single signon technique for authentication. This article will explore the approach and provide the details of implementation using some third party libraries and customizing it to the requirements. The Authentication will be done using the following networking portals Yahoo  Gmail Facebook    Special thanks to my friend Sumit Khandelwal, for implementation of Facebook part (in fact he did it all!!) Except Facebook, all other ca...
2 comments
Read more

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

WPF Overview-Part-II

This post is in continuation to the last post. In this Post I’ll be exploring the Dependency Properties Dependency properties are similar to CLR properties with more advanced and complex features. The main difference between the CLR properties and dependency properties is, that the value of a normal .NET property is read directly from a private member in your class, whereas the value of a DependencyProperty is resolved dynamically when calling the GetValue() method that is inherited from DependencyObject . In case this description did not make sense, no need to worry, It will become clear by the time you reach end of this article. How the Value is Resolved in Dependency properties Every time a dependency property is accessed, it internally resolves the value by following the precedence from high to low. It checks if a local value is available, if not, check if a custom style trigger is active and I the similar manner continues until it finds a value. At last the default value is alwa...
Post a Comment
Read more