Please enable JavaScript.
Coggle requires JavaScript to display documents.
DESIGN PATTERNS - Coggle Diagram
DESIGN PATTERNS
SOLID
-
Open-Closed Principle
"SOFTWARE ENTITIES (Classes, Modules, Methods etc,) SHOULD BE OPEN FOR EXTENSION, BUT CLOSED FOR MODIFICATION"
-
Closed for Modification - Existing code remains unchanged, (code which will be different in child's class will base defined as abstract as well as class)
Use inheritance. Open for extension (can derive from base & override methods) [DERVIED CLASS]. [BASE CLASS] Closed for Modification (avoid modifying base class, which is already tested and working)
Identify common constant filed (to get rid of duplications in code) and identify the behavior that is gonna to change and make it abstract to make class open for extension
Another words: classes are open for inheritance & methods can be overridden and closed means that existing base classes should not be modified
Example with Inheritance: Calculator app: 1. Interface with perform method declaration and other that can implement it. [No already written and tested code will be modified, but just extended]
-
-
Liskov Substitution
We should be to substitute base class objects with child class & this should not alter behavior/characteristics of program. BROKEN THIS PRINCIPLE WHEN RECTANGLE/SQURE CLASS is in inheritance relationship instead of common interface. Picture this: 1. We create child square class
- We pass it to the method which accept parent Rectangle
- We expect in this particular method that we can set differ values for width and height, because it's rectangle expected behavior but not square (in that sense it won't work as a parent the application will fail)
To fix that:
- Create interface with common behavior and implement it in the particular classes instead.
Violation
-
-
Is violated when child class completely modifies the behavior/contract of base class method by overriding it.
-
-
-
-
-
Dependency Injection
DI is about making software components to explicitly declare their dependencies or collaborators through their APIs, instead of. With DI, the responsibility of providing the component dependencies and wiring object graphs is transferred from the components to the underlying injection framework.