S.O.L.I.D:
The First 5 Principles of Object Oriented Design
The First 5 Principles of Object Oriented Design
S.O.L.I.D is an acronym for the first five object-oriented design(OOD) principles
SOLID Principles is a coding standard that all developers should have a clear concept for developing software in a proper way to avoid a bad design.
When the developer builds a software following the bad design, the code can become inflexible and more brittle, small changes in the software can result in bugs. For these reasons, we should follow SOLID Principles.
When the developer builds a software following the bad design, the code can become inflexible and more brittle, small changes in the software can result in bugs. For these reasons, we should follow SOLID Principles.
S.O.L.I.D STANDS FOR:
When expanded the acronyms might seem complicated, but they are pretty simple to grasp.
S – Single-responsiblity principle
O – Open-closed principle
L – Liskov substitution principle
I – Interface segregation principle
D – Dependency Inversion Principle
Let’s look at each principle individually to understand why S.O.L.I.D can help make us
better developers.
Single-responsibility Principle
S.R.P for short – this principle states that:
A class should have one and only one reason to change, meaning that a class should have
only one job.
Example: A typical example could a EmailSender class:
This should just deal with sending an email out. this should not be responsible for loading the email content from database or even formatting the email content to be sent.
Example: A typical example could a EmailSender class:
This should just deal with sending an email out. this should not be responsible for loading the email content from database or even formatting the email content to be sent.
Open-closed Principle
Objects or entities should be open for extension, but closed for modification. This simply
means that a class should be easily extendable without modifying the class itself.
Creating new extension methods are the example of this principles.
Example: See the below code, there are 2 types of customer New and Existing, we have implemented If and Else for both customer. This is Ok if we have only these two type of customer.
class Customer
{
int Type;
void Add()
{
if (Type == 0)
{
Console.Write("AddNewCustomer");
}
else
{
Console.Write("AddExistingCustomer");
}
}
}
But what If we have to add new type? Here we modify our code to implement OCP, See the below code:
public class CustomerBetter
{
public virtual void Add()
{
Console.Write("AddNewCustomer");
}
}
class ExistingCustomer : CustomerBetter
{
public override void Add()
{
Console.Write("ExistingCustomer");
}
}
class AnotherCustomer : CustomerBetter
{
public override void Add()
{
Console.Write("AnotherCustomer");
}
}
Liskov substitution principle
All this is stating is that every subclass/derived class should be substitutable for their
base/parent class. https://medium.com/swlh
Interface segregation principle
A client should never be forced to implement an interface that it doesn’t use or clients
shouldn’t be forced to depend on methods they do not use.
Example: We have one interface ICustomer which have two function Add() and Read(). Customer1 class implementing the ICustome interface. This works perfectly fine here.
interface ICustomer
{
void Add();
void Read();
}
class Customer1 : ICustomer
{
void Add()
{
// Add functionality here!
}
void Read()
{
// Read functionality here!
}
}
Now we have another customer named Customer2 who wants to implement only Add() function from interface ICustomer . With the current interface It's not possible. Let's break the interface for two classes.
interface ICustomer
{
void Add();
}
interface ICustomerV2
{
void Read();
}
class Customer1 : ICustomer, ICustomerV2
{
// Implement Add and read function both
}
class Customer2 : ICustomer
{
// Implement only Add function
}
Examples can be seen here, https://github.com/
Dependency Inversion principle
Entities must depend on abstractions not on concretions. It states that the high level module must not depend on the low level module, but they should depend on abstractions.
If we don’t follow SOLID Principles we
1. End up with tight or strong coupling of the code with many other modules/applications
2. Tight coupling causes time to implement any new requirement, features or any bug fixes and some times it creates unknown issues
3. End up with a code which is not testable
4. End up with duplication of code
5. End up creating new bugs by fixing another bug
6. End up with many unknown issues in the application development cycle
Following SOLID Principles helps us to
1. Achieve reduction in complexity of code
2. Increase readability, extensibility and maintenance
3. Reduce error and implement Reusability
4. Achieve Better testability
5. Reduce tight coupling
If we don’t follow SOLID Principles we
1. End up with tight or strong coupling of the code with many other modules/applications
2. Tight coupling causes time to implement any new requirement, features or any bug fixes and some times it creates unknown issues
3. End up with a code which is not testable
4. End up with duplication of code
5. End up creating new bugs by fixing another bug
6. End up with many unknown issues in the application development cycle
Following SOLID Principles helps us to
1. Achieve reduction in complexity of code
2. Increase readability, extensibility and maintenance
3. Reduce error and implement Reusability
4. Achieve Better testability
5. Reduce tight coupling
0 comments:
Post a Comment