The theory of SOLID principles was introduced by Martin in his 2000 paper "Design Principles and Design Patterns". The SOLID acronym was introduced later by Michael Feathers.
1. Single responsibility principle
A class should have only one reason to change
Martin defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, reason to be changed (i.e. rewritten).
"When designing our classes, we should aim to put related features together, so whenever they tend to change they change for the same reason. And we should try to separate features if they will change for different reasons." - Steve Fenton
2. Open-Closed Principle
A module should be open for extension but closed for modification.
Of all the principles of object oriented design, this is the most important.
It means simply this: We should write our modules so that they can be extended, without requiring them to be modified. In other words, we want to be able to change what the modules do, without changing the source code of the modules.
3. Liskov Substitution Principle
Subclasses should be substitutable for their base classes
This principle was coined by Barbar Liskov in her work regarding data abstraction and type theory. It also derives from the concept of Design by Contract (DBC) by Bertrand Meyer
Derived classes should be substitutable for their base classes. That is, a user of a base class should continue to function properly if a derivative of that base class is passed to it.
4. Interface Segregation Principle
Many client specific interfaces are better than one general purpose interface
The essence of the principle is quite simple. If you have a class that has several clients, rather than loading the class with all the methods that the clients need, create specific interfaces for each client and multiply inherit them into the class.
5. Dependency Inversion Principle
Depend upon Abstractions. Do not depend upon concretions
Dependency Inversion is the strategy of depending upon interfaces or abstract functions and classes, rather than upon concrete functions and classes. This principle is the enabling force behind component design, COM, CORBA, EJB, etc.
1. Single responsibility principle
A class should have only one reason to change
Martin defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, reason to be changed (i.e. rewritten).
"When designing our classes, we should aim to put related features together, so whenever they tend to change they change for the same reason. And we should try to separate features if they will change for different reasons." - Steve Fenton
2. Open-Closed Principle
A module should be open for extension but closed for modification.
Of all the principles of object oriented design, this is the most important.
It means simply this: We should write our modules so that they can be extended, without requiring them to be modified. In other words, we want to be able to change what the modules do, without changing the source code of the modules.
3. Liskov Substitution Principle
Subclasses should be substitutable for their base classes
This principle was coined by Barbar Liskov in her work regarding data abstraction and type theory. It also derives from the concept of Design by Contract (DBC) by Bertrand Meyer
Derived classes should be substitutable for their base classes. That is, a user of a base class should continue to function properly if a derivative of that base class is passed to it.
4. Interface Segregation Principle
Many client specific interfaces are better than one general purpose interface
The essence of the principle is quite simple. If you have a class that has several clients, rather than loading the class with all the methods that the clients need, create specific interfaces for each client and multiply inherit them into the class.
5. Dependency Inversion Principle
Depend upon Abstractions. Do not depend upon concretions
Dependency Inversion is the strategy of depending upon interfaces or abstract functions and classes, rather than upon concrete functions and classes. This principle is the enabling force behind component design, COM, CORBA, EJB, etc.
Comments
Post a Comment