SOLID Principles - amitbhilagude/userfullinks GitHub Wiki

  1. Single Responsibility Principal
    1. Each class needs to have a single responsibility. e.g. Logging class will only take care of logging functionality.
    2. Coupling, Cohesion, and Concerns
      1. Tight Coupling is bound with lots of details together and hard to manage.
      2. Loose coupling is splitting the work into multiple classes. e.g. DI mechanism
      3. Separation of concern is each program is separated into distinct sections. E.g. Web API layer, Database layer, etc.
      4. Cohesion: Relationship within classes is called cohesion. Class with multiple fields has been accessed by a lot of methods then it is called highly cohesive. Having multiple relationships will create a lot of challenges. Use decoupling for this case.
  2. Open Close Principal
    1. Class should be open to extend and close to modify that means for any additional functionality you should be able to extend the class easily without impacting existing functionality.
    2. Options to follow the principal
      1. Implement Inheritance so that you can extend as many derived classes without impacted the existing
      2. Dependency injections: Give responsibility to other classes in Inject
      3. Extensions method: Use of extension method to extend existing class functionality
      4. Using Abstract class or Virtual methods
  3. Liskov Principal
    1. Extended class with the help of the Open close principle shouldn't break the functionality of the base class
    2. E.g. Base class is Rectangle and assume extended this class for Square. All squares are rectangles so when we call the GetRectangles method, It should return all rectangles including squares. If we call the get area method, the area should be calculated correctly irrespective of the square or rectangle you provided.
  4. Interface Segregation Principal
    1. Do not create a large interface, only expose methods that are relevant to the consumer.
    2. Splitting up one large interface with multiple interfaces is the best practice so that consumers can use one of them which is relevant to them.
  5. Dependency Inversion Principal
    1. This is a combination of abstraction and loosely coupled. Abstraction is the client doesn't have to worry about the actual implementation he can only worry about parameter to be passed and returns. Loose coupling creates an interface and injects it through the constructor. It will make loosely coupled architecture. this process is called Dependency Injections. That means the dependency Injection and dependency Inversion principle go hand in hand.