SOLID Principles:

#SOLID Principles:

SOLID is a mnemonic device for 5 design principles of object-oriented programs that result in readable, adaptable, and scalable code. SOLID can be applied to any OOP program. SOLID has 5 principles. These principles provide us with ways to move from tightly coupled code and little encapsulation to the desired results of loosely coupled and encapsulated real needs of a business properly. SOLID is an acronym of the following. The 5 principles of SOLID are:

● Single-responsibility principle

● Open-closed principle

● Liskov substitution principle

● Interface segregation principle

● Dependency inversion principle

Why is solid required?

The SOLID Design Principles in C# are the design principles that help us to solve most of the software design problems. These design principles provide us with multiple ways to move the tightly coupled code between the software components which makes the software designs more understandable, flexible, and maintainable. The broad goal of the SOLID principles is to reduce dependencies so that engineers change one area of software without impacting others. Additionally, they're intended to make designs easier to understand, maintain, and extend.

Single-responsibility principle:

The single-responsibility principle states that each class, module, or function in your program should only do one job. In other words, each should have full responsibility for a single functionality of the program. The class should contain only variables and methods relevant to its functionality. Classes can work together to complete larger complex tasks, but each class must complete a function from start to finish before it passes the output to another class. It is easy to hide data from the user when all data and methods for a job are within the same single-responsibility class.

Pros:

The benefit of programs that follow SRP is that one can change the behavior of a function by editing the single class responsible for it. Also, if a single functionality breaks, one can know where the bug will be in the code and can trust that only that class will break.

Open-closed principle:

Open closed principle states that Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. This principle suggests that the class should be easily extended but there is no need to change its core implementations. The open-closed principle calls for entities that can be widely adapted but also remain unchanged. This leads us to create duplicate entities with specialized behavior through polymorphism. Through polymorphism, we can extend our parent entity to suit the needs of the child entity while leaving the parent intact.

Pros:

It minimizes program risk when you add new uses for an entity. Instead of reworking the base class to fit a work-in-progress feature, you create a derived class separate from the classes currently present throughout the program. We can then work on this unique derived class, confident that any changes we make to it will not affect the parent or any other derived class.

Liskov substitution principle:

The principle says that any class must be directly replaceable by any of its subclasses without error. In other words, each subclass must maintain all behavior from the base class along with any new behaviors unique to the subclass. The child class must be able to process all the same requests and complete all the same tasks as its parent class. It ensures that a derived class does not affect the behavior of the parent class, in other words,, that a derived class must be substitutable for its base class.

Pros:

programmers tend to develop classes based on behavior and grow behavioral capabilities as the class becomes more specific. The advantage of LSP is that it speeds up the development of new subclasses as all subclasses of the same type share a consistent use.

Interface segregation principle:

The interface segregation principle (ISP) requires that classes only be able to perform behaviors that are useful to achieve its end functionality. In other words, classes do not include behaviors they do not use. An interface should be more closely related to the code that uses it than code that implements it. So the methods on the interface are defined by which methods the client code needs rather than which methods the class implements. So clients should not be forced to depend upon interfaces that they don't use.

Pros:

The advantage of ISP is that it splits large methods into smaller, more specific methods. This makes the program easier to debug for three reasons:

● There is less code carried between classes. Less code means fewer bugs.

● A single method is responsible for a smaller variety of behaviors. If there is a problem with a behavior, you only need to look over the smaller methods.

● If a general method with multiple behaviors is passed to a class that doesn’t support all behaviors (such as calling for a property that the class doesn’t have), there will be a bug if the class tries to use the unsupported behavior.

Dependency inversion principle:

This principle states that One should depend upon abstractions, not at concretions. The Dependency Inversion Principle (DIP) states that high-level modules/classes should not depend on low-level modules/classes. Both should depend upon abstractions. Secondly, abstractions should not depend upon details. Details should depend upon abstractions. High-level modules/classes implement business rules or logic in a system (application). Low-level modules/classes deal with more detailed operations; in other words they may deal with writing information to databases or passing messages to the operating system or services. Without DIP, programmers often construct programs to have high-level (less detail, more abstract) components explicitly connected with low-level (specific) components to complete tasks. DIP decouples high and low-level components and instead connects both to abstractions. High and low-level components can still benefit from each other, but a change in one should not directly break the other.

Pros:

The advantage of this part of DIP is that decoupled programs require less work to change. Webs of dependencies across your program mean that a single change can affect many separate parts.