Learning solid principles using c#
Download as PPTX, PDF5 likes1,449 views
The document outlines the S.O.L.I.D principles in C#, which include the Single Responsibility Principle, Open Closed Principle, Liskov's Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle. Each principle is defined with guidelines on how to implement it, emphasizing the importance of class design, abstraction, and reducing dependencies to enhance code modularity and maintainability. Key recommendations involve avoiding over-engineering and assessing the appropriate application of S.O.L.I.D principles in relation to project size.
Learning solid principles using c#
- 2. And the principles are… S Single Responsibility Principle O Open Closed Principle L Liskovs Substitution Principle I Interface Segregation Principle D Dependency Inversion principle
- 3. Single Responsibility Principle “A class should have one reason to change” Meaning There can be only one requirement that when changed, will cause a class to change. How to do this ? breaking your story/requirement/code to smaller chunks/class in such a way that all common behavior is being grouped together under one component. Single Responsibility means your class to be very focused Outcome You will end up having multiple classes, precise about one specific behavior. Each of this class can now be used as a component.
- 4. Open Closed Principles “Your class/module/contracts should be open for extension and closed for modification” Meaning You should be able to extend the behavior of a class without changing it. Once a class is done, it should not be modified. How to do this ? Creating new class by using inheritance or abstraction
- 5. Open Closed Principle To implement OCP, we should be SRP, so that we can identify and separate behavior that change into multiple classes, such that things that change frequently depends on things that don’t. Output Lots of components(class) for same behavior but different implementation
- 6. Liskovs Substitution Principle “If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2, then S is a subtype of T.” Meaning We should be able to substitute every derived class for there parent class. A subclass (outcome of OCP) should behave in such a way that it will not cause problem when used instead of its super class(outcome of SRP)
- 7. Liskovs Substitution Principle How to do this ? Pre conditions cannot be strengthened in a subtype & Post conditions can not be weakened in a subtype. No new exceptions types are allowed to be thrown unless they are subclasses of previously used one. You can not make mutable to immutable vice versa. Output Plug and play components.
- 8. Interface Segregation Principle “Clients should not be forced to depend upon interfaces that they don’t use.” How to do this? Breaking down interfaces in smaller pieces and combining interfaces to generate a super interfaces. Output Smaller Interfaces with specific responsibility.
- 9. Dependency Inversion Principle “High level module should not depend on low level module. Both should depend on abstraction. Abstraction should not depend upon details. Details should depend upon abstraction.” Meaning Your classes should not depend on specific implementation, avoid instantiation of a class X inside another Y, as this makes your class Y directly dependent on X and any change in X might break Y.
- 10. Dependency Inversion Principle Example: If business decides to change Business Logic or database, this model does for a complete change, because business login is directly instantiating repository layer and same for UI. UI is calling business logic layer by directly creating an object of it. We should not use NEW keyword inside a class as this creates a dependency. How to do this? By using Interfaces or Abstract classes to create generic types or holder to hold any class implementing that interface or abstract class. By not using NEW keyword to instantiate an object and instead inject the dependencies using constructor or property. If NEW is not to be used, then who will create required object? We achieve this by using Dependency Injection tools like Unity, Structure Map. By having a Abstract Factory Method responsible for create of new object. UI Layer Reposi tory Layer Busine ss Logic DB
- 11. Done !!! Few Points to consider… Try avoiding over engineering and keep the solution simple and readable. Decide how far you want to go with SOLID, as splitting requirement to SOLID principles is debatable. Project size (LOC)