Please enable JavaScript.
Coggle requires JavaScript to display documents.
SOLID (Dependency inversion principle (Dependency injection (DI) -…
SOLID
Dependency inversion principle
High level modules should not depend on low level modules, they should both depend on abstractions
Abstracions should not depend on details, details should depend on abstractions
Dependencies - Third party libraries, Database, File System, Email, Web Services, System resources(Clock), Configuration, The New Keyword, Static Methods, Thread.Sleep, Random
Dependency injection (DI) - technique that is used to allow calling code to inject the dependencies that class needs when it is instantiated
Class constructor should require any dependencies that class needs. If not then the class has hidden dependencies - it's lying, not being honest (Strategy pattern)
Ways to do it:
1.constructors - default and DI constructor
New up instaces in startup routine (main method)
IoC container
Facade pattern
Strategy pattern
Single Responsibillity Principle - every object should have a single responsibillity and that responsibillity should be entirely encapsulated by the class
High Cohesion - how related are the responsibilltyes of a module(class)
Low Coupling - the degree of which one module relies on others
More resposibillites - more likelihood of change
Problem - one class for orders for web sale and store sail -> they require different methods for checkout
Solution - Base class order and child classes for web and store sail which implement interfaces for each checkout operation (Reserve item, Notify customer, Proccess credit card...)
Open/Closed Principle - software entites(classes, modules, functions...) should be open for exstenstion but closed for modification
Should rely on abstractions - abstract classes and interfaces
Problem - method for calculationg total order amound based on benefits (specials, discouns, quantity) - for each new benefit we have to add a condition to the method(more bugs)
Possible solutions
Inheritance/Template method pattern - Child types override the behavior of the base class or interface
Composition - Strategy pattern -> Find abstractions and add class for every condition
Patameters (Procedural programming) - e.g. introduce a parameter to define folder save path instead of changing the code
Solution (Strategy pattern) - Separate Class for every benefit, each class through interface implements their calculation method
Can add complexity to the design - use only if you need it
Interface Segregation Principle - Clients should not be force to depend on methods they dont use. Prefer small cohesive to fat interfaces
Problem - fat interfaces - not all members are being used by the class that implements the interface(e.g. appConfig)
Solution - general interfaces that implemet specific ones.
e.g. IAppConfig: IAppIdentityConfig - if you need only AppIdentityConfig members you inject that interface in the class constructor
Facade pattern
Liskov Substitution Principle - Subtypes must be substitutable for their base types.
Child class must not remove base class behavior
Child class must not violate base class invariants(constraintas)
DRY - Don't repeat youtself principle
Template method pattern
Command pattern
Dependency inversion