SOLID Principles and Design Patterns plays a key role in achieving Maintainability, Testability, Flexibility and Extensibility, Parallel Development and Loose Coupling. In any enterprise software application development when we design and develop software systems, we need to account for the below factors during the development cycle.
As per the single responsibility principle,
- A class should have only one reason to change
- Which means, every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class.
In Single Responsibility Principle,
- Each class and module should focus on a single task at a time
- Everything in the class should be related to that single purpose
- There can be many members in the class as long as they related to the single responsibility. Should not mix more than one responsibility
- With SRP, classes become smaller and cleaner which helps to maintain
- Code is less fragile
Let’s discuss the task which is most common in any application.
Basically it is the Customer Login, Customer Registration, Logging Exception or Error during the Registration process or Login process and Sending email after registration of user.
Below code demonstrates how we can achieve Single Responsibility Principle
Code before Single Responsibility Principle
- namespace SRPImplementation
- {
- interface ICustomer
- {
- bool Login(string username, string password);
- bool Register(string username, string password, string email);
- void LogError(string error);
- bool SendEmail(string emailContent);
- }
- }
In above code all 4 tasks or functionality related functions are defined in single class. It will definitely serve the purpose of all 4 tasks, however it is the violation of Single Responsibility principle. Method 1 and 2 are related to Customer so both methods should be in the ICustomer interface.
But the other 2 methods must not be in ICustomer interface as responsibility of both functions are different that Customer activity. Logging Error and Sending email are the most common functionalities in any application, that’s why those methods should have separate interfaces and implementation so that we can use it anywhere in application.
Code after Single Responsibility Principle
- namespace SRPImplementation
- {
- interface ICustomer
- {
- bool Login(string username, string password);
- bool Register(string username, string password, string email);
- }
- interface IErrorLogger
- {
- void LogError(string error);
- }
-
- interface IEmail
- {
- bool SendEmail(string emailContent);
- }
- }
Now in the above code we have separated the responsibility of related tasks. We have separated related tasks. Two tasks are in ICustomer interface. And there is a separate interface for Email and Error logging. In this segregation if you need to do any change in tasks you can make a change in a separate interface which will avoid the impact on other tasks.
Also different developers can work on different interface functionalities. With this separation we are achieving all core principles of SOLID which are Maintainability, Testability, Flexibility and Extensibility, Parallel Development and Loose Coupling. Any big or enterprise application which fails to achieve these 5 core concepts ultimately gets messed up after some years as software development and maintenance is a continuous process.
--Happy Coding--
Edmond DantesPosted Oct 13, 2019, 9:37 PM
If I want to record register client information,such as ip address to another table,maybe I have a SaveIp method in IIpAddress, but I need to save register information and ip by transaction,how should I process this situation?thanks and sorry for my bad English.
GTrevellick GTrevellickPosted Sep 21, 2019, 1:15 AM
Is the example above also demonstrating the Interface Segregation principle?