The principles of SOLID programming

Hello there! Today I’ll be explaining The principles of SOLID programming. When I first got serious about OOP, I jumped to design patterns, but then I realized that everyone need a good grasp of the SOLID principles before you’re ready to tackle Design Patterns – in more of an Architect role – that is. So, to conclude this short introduction, I’ll try to explain this in as low-level of knowledge as possible.

Well, yous should know that SOLID stands for:

Single responsibility principle
Open-closed principleLiskov substitution principleInterface segregation principleDependency inversion principle

Those are five basic patterns used in OO Programming and OO Design Those are the principles that can be used in agile and test driven development. Also, those are a good principles, good advices, but it’s not pure truth, nor is it a rule.Just a quote of a sentence I ran into internet: “They are common-sense disciplines that can help you stay out of trouble”. That’s why it’s a good idea.

Let me introduce you to them one by one:

It states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility. In other words the meaning of this phrase is that when you’re adding features to your application, two different, unrelated stories to implement should not affect the same class.

The meaning of this principle is that when a get a request for a feature that needs to be added to your application, you should be able to handle it without modifying old classes, only by adding subclasses and new implementations (in pure OOP language – extending old ones  ).

The meaning of this principle is that every time you extend a class, you have to make sure it is substitutable in every place where you use an instance of the original class. Extended class must respect the contract of the parent class. Meaning that you should edit it in a way so that it will stay recognizable compared the the parent class.

This one means that you should avoid getting your classes included to other ones if only small portion of it will be used (say 3 out of 12). Often you will see classes with too much methods implemented in it which it’s not a good idea because it conflicts with Single Responsibility Principle in a way. Basically, if you don’t listen to this one, its considered to be a “bad design”.

Well, as last principle, I find it most valuable. It says that you should decouple your software modules. To achieve that you’d need to isolate dependencies. Why you might ask? Well, the answer is simple – for code re-usage. This way you’ll get more efficient and affordable at the same time. That’s why I find it most valuable.

In our environment (around 20 people) – this helps. It helps because when we have to do additional work on project done by other developer, you don’t have to trace code line by line, you only need to think logically, and you’re there. Besides the “Dependency Inversion Principle”, this I value the most in SOLID programming.

I’d like to conclude this one by repeating myself: “They are common-sense disciplines that can help you stay out of trouble”, they aren’t rules.

Cheers!

To post code in comments, place your code inside [code] and [/code] tags.

View the original article here

High Conversions and High Payouts = Huge Money! Visit www.profitpal.com for affiliate tools or email us at contact@profitpal.com for more info.

Check it out!