Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Do you really want to delete this prezi?
Neither you, nor the coeditors you shared it with will be able to recover it again.
Make your likes visible on Facebook?
You can change this under Settings & Account at any time.
Transcript of SOLID principles
is not a
is bound to change
Open / Closed principle
"Software entities should be opened for extension, but closed for modification."
Liskov's Substitution principle
"Subtypes must be substitutable for their base types."
Dependency Inversion principle
"High level modules should no depend upon low level modules. Rather, both should depend upon abstractions."
Interface segregation principle
"Clients should not be forced to depend upon interfaces that they do not use."
Single Responsibility principle
"There should never be more than one reason for a class to change"
Why Does it matter?
1. More responsibilities means more likelihood to change
2. Having more responsibilities in a module/class/function means they are tied together
3. This kind of coupling leads to fragile designs that break in unexpected ways when changed.
Symptoms that code has multiple responsibilities
1. A lot of branching in code : if($x), switch($y), etc.
2. Functions that constantly check values of parameters to figure out what they should do
3. Conjunctions in method names:
4. Business logic that leaks into graphical interface code and vice versa
Open / Closed principle
When we design modules, classes and functions we should keep in mind that when a new functionality is needed, we should
our existing code but rather
write new code
that will be used by existing code.
OCP - Solution
Separate extensible behavior behind an INTERFACE, and flip the dependencies.
SRP - Bad example
SRP - Fixed
Separate extensible behavior behind an interface
OCP - Bad Solution
Flip the dependencies
If code required changes once, there's a high possibility it will require change again.
When a possibility turns into reality, OCP will save you a lot of time and effort.
is your code