Understanding the SOLID Principles
This week the blog will talk about the article "Understanding the SOLID Principles" written by Edward Guiness, this is a brief summary that presents the definition of the SOLID Principles.
The general objective of the SOLID principles, and so the author in the article, is to implement best practices in the creation of objects and classes in specific cases depending on the situation that is presented.
And with you, the 5 principles *drumroll*:
• Single Responsibility Principle
• Open/Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle
The first of this is the Single Responsibility Principle, it says that a class, should have just exactly one responsibility, just one reason or an only class of reason to exist. This responsibility should be implemented to the class, so for this reason a class just has one reason to be modified. Why implement this? Easy, in a big project you will have lots of classes and many lines of code, so finding a bug will be an almost impossible task if you do not know what is happening and where it is and where this should be doing.
The second principle, the Open/Closed Principle establishes that a class or function should be open for extension but closed for modification which show us that a class have to be constructed in to be flexible and adaptable for the conditions that exist in the new particular situation but this class doesn't have to be internally modifiable from outside.
The third principle, the Liskov Substitution Principle on establishes that two classes can be interchangeable where these two classes have an inheritance link between them so it will provide a characteristic of flexibility to the function.
The Interface Segregation Principle, the ISP just says that a good way to avoid writing disastrous interfaces that burden classes with responsibilities they don't need or want. You should create a collection of smaller, discrete interfaces for the specific purposes.
The final principle, called Dependency Inversion (DIP), says that classes should not be dependent of the abstractions, and also that the abstractions should not depend of the abstractions.
The general objective of the SOLID principles, and so the author in the article, is to implement best practices in the creation of objects and classes in specific cases depending on the situation that is presented.
And with you, the 5 principles *drumroll*:
• Single Responsibility Principle
• Open/Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle
The first of this is the Single Responsibility Principle, it says that a class, should have just exactly one responsibility, just one reason or an only class of reason to exist. This responsibility should be implemented to the class, so for this reason a class just has one reason to be modified. Why implement this? Easy, in a big project you will have lots of classes and many lines of code, so finding a bug will be an almost impossible task if you do not know what is happening and where it is and where this should be doing.
The second principle, the Open/Closed Principle establishes that a class or function should be open for extension but closed for modification which show us that a class have to be constructed in to be flexible and adaptable for the conditions that exist in the new particular situation but this class doesn't have to be internally modifiable from outside.
The third principle, the Liskov Substitution Principle on establishes that two classes can be interchangeable where these two classes have an inheritance link between them so it will provide a characteristic of flexibility to the function.
The Interface Segregation Principle, the ISP just says that a good way to avoid writing disastrous interfaces that burden classes with responsibilities they don't need or want. You should create a collection of smaller, discrete interfaces for the specific purposes.
The final principle, called Dependency Inversion (DIP), says that classes should not be dependent of the abstractions, and also that the abstractions should not depend of the abstractions.
Comentarios
Publicar un comentario