Understanding the SOLID Principles
Understanding the SOLID principles
SOLID is an acronym that stands for five widely accepted principles of object-oriented programming and design. These principles are:
➜ S |
Single Responsibility Principle
|
➜ O |
Open/Closed Principle
|
➜ L |
Liskov Substitution Principle
|
➜ I |
Interface Segregation Principle
|
➜ D |
Dependency Inversion Principle
|
The Single Responsibility Principle (SRP) declares a class should have exactly one responsibility.
Here is a violation of the principle extracted from the article:
var myReport = new CashflowReport();
formatReportHeader(myReport);
printReport(myReport);
void formatReportHeader(Report report) {
report.Header.Bold = true;
if (report is CashflowReport && report.Content.Profit < 10000) {
SendAlertToCEO("Profit warning!");
}
}
Nothing unusual until its ask for the report header to be reset to the default format, without any bold bits.
The programmer in charge of the modification deletes the second line, leaving the code as follows:
var myReport = new CashflowReport();
printReport(myReport);
void formatReportHeader(Report report) {
report.Header.Bold = true;
if (report is CashflowReport && report.Content.Profit < 10000) {
SendAlertToCEO("Profit warning!");
}
}
Now Profit warning is no longer send, so caotic. What could have being a good alternative?, to split the warning part form the formatReportHeader method.
Open/Closed Principle declares a class or function should be open for extension but closed for modification.
This is easier to understand and to follow, you just need to respect that when adding new behavior leave base classes alone and instead create new, inheriting class, these will avoid future problems.
Liskov Substitution Principle pretends to keep a well and working the relationship between classes and functions. Just like the OCP principle the LCP states you should not modify the behavior of base class, with the only difference that LSP stands against modifying of the base class behavior through inheritance.
Remember experience tells us changing the behavior of a class brings problems.
Interface Segregation Principle states to avoid writing monstrous interfaces that add classes with responsibility don't needed or wanted. Instead create a a collection of smaller, discrete interfaces, dividing interface members according to what they concern.
The article presents this example of these monstrous interfaces:
public interface IOneInterfaceToRuleThemAll {
void DoThis();
void DoThat();
void GoHere();
void GoThere();
bool MyFavoriteTogglyThing {get; set;}
string FirstName {get; set;}
string LastName {get; set;}
}
And an alternative:
public interface IActionable {
void DoThis();
void DoThat();
}
public interface IMovable {
void GoHere();
void GoThere();
}
public interface IToggly {
bool MyFavoriteTogglyThing {get; set;}
}
public interface INamed {
string FirstName {get; set;};
string LastName {get; set;}
}
Dependency Inversion Principle declares "depend upon abstractions, not upon concretions". So that instead of writing code that refers to actual classes, write code that refers to interface or abstract classes.
For example:
class B {
// ...
}
class A {
public void DoSomething() {
B b = new B(); // A now depends on B
}
}
Here class has dependency with class B.
Now a solution following what dependency inversion principle states:
interface IB {
// ...
}
class B : IB {
// ...
}
class AlternativeB : IB {
// ...
}
class A {
public void DoSomething(IB b) {
// b can be either B or AlternativeB
}
}
Now dependency is gone, instead it depends on interface IB.
These principles may be new for you but it's worth it to use them when using object oriented programming, eventually it will avoid you having problems.
References:
http://34.212.143.74/s202011/tc3049/solid.html
Comentarios
Publicar un comentario