SOLID
At wikipedia we can read that SOLID is a mnemonic acronym for 5 design principles intended to make software designs more understandable, flexible and maintainable. The principles are a subset of many principles promoted by Robert C. Martin.
Though they apply to any object-oriented design, the SOLID principles can also form a core philosophy for methodologies such as agile development or adaptive software development.
SOLID concepts are as follows:
= "software entities … should be open for extension, but closed for modification."
Example of "Immutable Class in Java":
See deeper if You want at https://www.journaldev.com/129/how-to-create-immutable-class-in-java
Simply said, any object can be replaced by an object of its child class.
Animal animal = new Cat();
animal.getSpeed();
animal = new Tiger();
animal.getSound();
ISP states that no client should be forced to depend on methods it does not use.
ISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them.
Such shrunken interfaces are also called role interfaces.
ISP is intended to keep a system decoupled and thus easier to refactor, change, and redeploy.
ISP is one of the five SOLID principles of object-oriented design, similar to the High Cohesion Principle of GRASP.
This is a specific form of decoupling software modules...
When following this principle, the conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are reversed, thus rendering high-level modules independent of the low-level module implementation details.
By dictating that both high-level and low-level objects must depend on the same abstraction this design principle inverts the way some people may think about object-oriented programming (OOP)...
Single responsibility principle, SRP
= a class should have only a single responsibility (i.e. only changes to one part of the software's specification should be able to affect the specification of the class).
Open/closed principle, OCP
= "software entities … should be open for extension, but closed for modification."Example of "Immutable Class in Java":
- Declare the class as final so it can't be extended.
- Make all fields private so that direct access is not allowed.
- Don't provide setter methods for variables.
- Make all mutable fields final so that it's value can be assigned only once.
- Initialize all the fields via a constructor performing deep copy.
- Perform cloning of objects in the getter methods to return a copy rather than returning the actual object reference.
See deeper if You want at https://www.journaldev.com/129/how-to-create-immutable-class-in-java
Liskov substitution principle, LSP
= "objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program." See also "design by contract"...Simply said, any object can be replaced by an object of its child class.
Animal animal = new Cat();
animal.getSpeed();
animal = new Tiger();
animal.getSound();
Interface segregation principle, ISP
= "many client-specific interfaces are better than one general-purpose interface."ISP states that no client should be forced to depend on methods it does not use.
ISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them.
Such shrunken interfaces are also called role interfaces.
ISP is intended to keep a system decoupled and thus easier to refactor, change, and redeploy.
ISP is one of the five SOLID principles of object-oriented design, similar to the High Cohesion Principle of GRASP.
Dependency inversion principle, DIP
= one should "depend upon abstractions, [not] concretions" what means:- High-level modules should not depend on low-level modules. Both should depend on abstractions.
- Abstractions should not depend on details. Details should depend on abstractions.
This is a specific form of decoupling software modules...
When following this principle, the conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are reversed, thus rendering high-level modules independent of the low-level module implementation details.
By dictating that both high-level and low-level objects must depend on the same abstraction this design principle inverts the way some people may think about object-oriented programming (OOP)...
No comments:
Post a Comment