SOLID : Open / Closed Principle

The Open / Closed Principle focuses on one basic requirement, the classes should be Open for extensions, but closed for modification.

The better way to explain the principle would be to first express the issue in hand. Consider the below class.

image

The class itself looks good, but what if in future one needs to add another Shape, say Circle. This would raise need to modify our existing class which is violation of OCP.

The solution to problem lies in achieving extension by deriving from abstraction. Let’s rewrite the code.

image

As you can see in the above implementation, we have created an abstract class with the function we might require extension. The corresponding classes, Square and Circle, implement this abstract class and extend its functionality. So when the requirements changes, and you need to extend, you needn’t change the existing classes. This means the classes which are properly tested needn’t be touched again and thereby reduce chances of introducing bugs in existing classes.

SOLID : Single Responsibility Principle

While OOPs is rich with features like inheritance, polymorphism, encapsulation and overloading enabling developers to extract more from modern day programming languages like C#, it is equally important to understand when to use these features based on design principles.

SOLID, is a set of 5 principles which when properly applied intend to guide a programmer to make systems that is scalable and maintainable with ease.

The first of SOLID Principles, (S) – Single Responsibility Principle (SRP) demands that a class should have only a single responsibility and that responsibility should be fully encapsulated by that a class.

Consider the following class. The class is intended to Book Movie Tickets.

image

If you observe the class, the method BookTicket is divided into two parts. First, it books the tickets and then it notify the User about the same. That is, the class has two responsibilities – Book Tickets and Notify User, in other words, there are two reasons for which the class can be changed.

Suppose few years later, the company decides to change the notification mechanism and include SMS support as well. This would mean our MovieTicket Class needs to be altered for a reason (user notification), which has nothing to do with the core functionality of the class (booking ticket).

This is violation of SRP and the obvious solution would be to separate the responsibilities to separate classes.

image

This ensures that each class has only one responsibility and there would be only reason to change it.