Did you know around 47 percent of projects had higher-than-expected maintenance costs? But why is that?
Have you ever worked on a project that is?
1-Rigid
The design is hard to change. It is very difficult to modify, either to change existing functionality or add new feature. Most of tasks are under estimated and you keep hearing “oh man, it was a lot more complicated than I thought.” from engineering team
2-Fragile
There is no design . Changes cause cascading effects to many places. The code breaks in unexpected places that have no conceptual relationship with the changed area. fixing the problems causes new problems. Keep hearing “not again” a lot from testing team
3-Immobility - Non-reusable
The design is hard to reuse
the code is so tangled that it is impossible to reuse anything
imagine you want to reuse a login module than has been developed by another team and
hearing “a module could be reused but the effort and risk of separating it is too high and takes longer than writing it from scratch” from engineering team
In object oriented programming is based on three pillars
1- Encapsulation
2- Inheritance
3- Polymorphism
Robert C. Martin (uncle bob) introduced five basic principles of object-oriented programming and design in the early 2000s.Luckily, if we apply those together, it helps us to create a system that is easy to maintain and extend over time.
What is SOLID?
1.Single-Responsibility Principle (SRP):
A class should have only one reason to change.
A responsibility is “a reason for change” in this context, when a class has more than one responsibility, there are also more triggers and reasons to change that class.
It doesn’t mean a class should have only one method, it means all the methods in the class should be related to the class's primary function. In other words, it should have only one job to do.
Real world non-technical example:
Imagine each body organ is a class. If you think about it. you can quickly realize each of them does only one job and they have one responsibly. Your heart is responsible for pumping blood. Your lungs are responsible for absorbing oxygen and removing carbon dioxide.
Imagine your kidney was responsible for your pumping blood and filters blood and takes the waste?
how would be difficult if a surgeon wants to do kidney transplant or small surgery?
how much time will it take for a small surgery?
how much knowledge your surgeon should gather and analysis before operation?
what would be the side effects after surgery?
2.Open–Closed Principle (OCP):
Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.
“Open to extension” means that you should design your classes so that new functionality can be added as new requirements are generated.
“Closed for modification” means that once you have developed a class no one should modify it.
but how does it possible? how can we extend a class without modifying it!!! These two parts of the principle appear to be contradictory!
A class is closed, since it may be compiled, stored in a library and used by client classes. But it is also open, since any new class may use it as parent, adding new features. When a descendant class is defined, there is no need to change the original or to disturb its clients
Real world non-technical example:
Imagine you have a kid and you want your kid learns how to swim, do you take him to doctor and ask for operation appointment so you kid can swim! No! you don’t modify your kid’s abilities.
You take him/her to activity centre and enrol him in swimming class and extend his abilities to float, to dog paddle and to swim
3.Liskov Substitution Principle
if S is a subtype of T, then objects of type T may be replaced with objects of type S
code that uses a base class must be able to substitute a subclass without knowing it. An object should be substitutable by its base class (or interface).
Real world non-technical example:
Imagine of dishwasher tablet as base class with one public method clean, you go to super market and chose any dishwasher tablet because they all inherited from same base class and when you get home and put it dish washer you expect it to cleans dishes and doesn’t explode the dishwasher!
4.Interface-Segregation Principle
client should not be forced to depend on methods it does not use
This means that when one class is dependent to another, the number of members in the interface that is visible to the dependent class should be minimised.
Real world non-technical example:
Do you remember you wanted to extend the swimming abilities of your kid and took it to activity centre to extend your kids abilities to swimming? Imagine the principle says, sorry you cannot enrol your kid only to learn swimming. Since our class are bundled and in order you kid learns how to swim he needs to go to tap dancing classes and drawing and singing and you need to pay for all together although your kid doesn’t want to go to those classes.
5.Depency-Inversion Principle
A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend on details. Details should depend on abstractions.
Real world non-technical example:
Imagine in your organization you need to deliver a website (high level module). The website shouldn’t be dependent on individuals (Eric, Lisa, …) or how they do their job. It should depend on disciplines (abstracts) like developer, BA, PM, Tester!
Also your PM(abstraction) shouldn’t be depend on individuals. Let’s say our PM only can work with Tess and Eric! Your PM can work with other disciplines (abstracts) (designer, UX, Developer and tester)
Applying solid principle to your code is not hard and it doesn’t need massive investment, but the benefit you will get by applying it is not ignorable. Your code will be easily extended, modified, tested, and refactored without any problems.
May SOLID become a part of you and your code
slides:
https://docs.google.com/presentation/d/1wov4uJh-geJF0VoT_GwhFPJJ1D0M2kGZFRhEooMD-pc/edit?usp=sharing
resources:
http://www.cnet.com/news/62-percent-of-it-projects-fail-why/
https://en.wikipedia.org/wiki/Single_responsibility_principle
https://en.wikipedia.org/wiki/Open/closed_principle
https://en.wikipedia.org/wiki/Liskov_substitution_principle
https://en.wikipedia.org/wiki/Interface_segregation_principle
https://en.wikipedia.org/wiki/Dependency_inversion_principle
http://williamdurand.fr/2013/07/30/from-stupid-to-solid-code/
Have you ever worked on a project that is?
1-Rigid
The design is hard to change. It is very difficult to modify, either to change existing functionality or add new feature. Most of tasks are under estimated and you keep hearing “oh man, it was a lot more complicated than I thought.” from engineering team
2-Fragile
There is no design . Changes cause cascading effects to many places. The code breaks in unexpected places that have no conceptual relationship with the changed area. fixing the problems causes new problems. Keep hearing “not again” a lot from testing team
3-Immobility - Non-reusable
The design is hard to reuse
the code is so tangled that it is impossible to reuse anything
imagine you want to reuse a login module than has been developed by another team and
hearing “a module could be reused but the effort and risk of separating it is too high and takes longer than writing it from scratch” from engineering team
In object oriented programming is based on three pillars
1- Encapsulation
2- Inheritance
3- Polymorphism
Robert C. Martin (uncle bob) introduced five basic principles of object-oriented programming and design in the early 2000s.Luckily, if we apply those together, it helps us to create a system that is easy to maintain and extend over time.
What is SOLID?
1.Single-Responsibility Principle (SRP):
A class should have only one reason to change.
A responsibility is “a reason for change” in this context, when a class has more than one responsibility, there are also more triggers and reasons to change that class.
It doesn’t mean a class should have only one method, it means all the methods in the class should be related to the class's primary function. In other words, it should have only one job to do.
Real world non-technical example:
Imagine each body organ is a class. If you think about it. you can quickly realize each of them does only one job and they have one responsibly. Your heart is responsible for pumping blood. Your lungs are responsible for absorbing oxygen and removing carbon dioxide.
Imagine your kidney was responsible for your pumping blood and filters blood and takes the waste?
how would be difficult if a surgeon wants to do kidney transplant or small surgery?
how much time will it take for a small surgery?
how much knowledge your surgeon should gather and analysis before operation?
what would be the side effects after surgery?
2.Open–Closed Principle (OCP):
Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.
“Open to extension” means that you should design your classes so that new functionality can be added as new requirements are generated.
“Closed for modification” means that once you have developed a class no one should modify it.
but how does it possible? how can we extend a class without modifying it!!! These two parts of the principle appear to be contradictory!
A class is closed, since it may be compiled, stored in a library and used by client classes. But it is also open, since any new class may use it as parent, adding new features. When a descendant class is defined, there is no need to change the original or to disturb its clients
Real world non-technical example:
Imagine you have a kid and you want your kid learns how to swim, do you take him to doctor and ask for operation appointment so you kid can swim! No! you don’t modify your kid’s abilities.
You take him/her to activity centre and enrol him in swimming class and extend his abilities to float, to dog paddle and to swim
3.Liskov Substitution Principle
if S is a subtype of T, then objects of type T may be replaced with objects of type S
code that uses a base class must be able to substitute a subclass without knowing it. An object should be substitutable by its base class (or interface).
Real world non-technical example:
Imagine of dishwasher tablet as base class with one public method clean, you go to super market and chose any dishwasher tablet because they all inherited from same base class and when you get home and put it dish washer you expect it to cleans dishes and doesn’t explode the dishwasher!
4.Interface-Segregation Principle
client should not be forced to depend on methods it does not use
This means that when one class is dependent to another, the number of members in the interface that is visible to the dependent class should be minimised.
Real world non-technical example:
Do you remember you wanted to extend the swimming abilities of your kid and took it to activity centre to extend your kids abilities to swimming? Imagine the principle says, sorry you cannot enrol your kid only to learn swimming. Since our class are bundled and in order you kid learns how to swim he needs to go to tap dancing classes and drawing and singing and you need to pay for all together although your kid doesn’t want to go to those classes.
5.Depency-Inversion Principle
A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend on details. Details should depend on abstractions.
Real world non-technical example:
Imagine in your organization you need to deliver a website (high level module). The website shouldn’t be dependent on individuals (Eric, Lisa, …) or how they do their job. It should depend on disciplines (abstracts) like developer, BA, PM, Tester!
Also your PM(abstraction) shouldn’t be depend on individuals. Let’s say our PM only can work with Tess and Eric! Your PM can work with other disciplines (abstracts) (designer, UX, Developer and tester)
Applying solid principle to your code is not hard and it doesn’t need massive investment, but the benefit you will get by applying it is not ignorable. Your code will be easily extended, modified, tested, and refactored without any problems.
May SOLID become a part of you and your code
slides:
https://docs.google.com/presentation/d/1wov4uJh-geJF0VoT_GwhFPJJ1D0M2kGZFRhEooMD-pc/edit?usp=sharing
resources:
http://www.cnet.com/news/62-percent-of-it-projects-fail-why/
https://en.wikipedia.org/wiki/Single_responsibility_principle
https://en.wikipedia.org/wiki/Open/closed_principle
https://en.wikipedia.org/wiki/Liskov_substitution_principle
https://en.wikipedia.org/wiki/Interface_segregation_principle
https://en.wikipedia.org/wiki/Dependency_inversion_principle
http://williamdurand.fr/2013/07/30/from-stupid-to-solid-code/
Comments