Why is the Single Responsability Principle important?

The Single Responsability Principle is one of the five S.O.L.I.D. principles in which i base my everyday programming. It tells us how a method or class should have only one responsability.

Not a long time ago i was designing a reporting service with my colleague Nuno for an application module we were redoing and we had a method that was responsible for being both the factory method of a popup view and showing it to the user. You can see where this is going now...

I figured out it would not be a that bad violation of the principle, so we moved on with this design. The method was called something like "ShowPrintPopup" and it took an IReport as an argument. All this was fine, but then we got to a point where we needed to have a permissions system to say if the user was able to export the report to Excel, Word, PDF, etc...

The problem was the print popup would need to know beforehand if it would allow the user to export the report or not, so that it could show it's UI accordingly. We decided the permissions behavior would be best implemented with the Decorator design pattern, so we could easily override it when using the Debug configuration. This allowed us to follow the Open-Closed Principle (the O in S.O.L.I.D.) by adding features without modifying code already tested.

So, we needed to apply the permissions to the Popup before it was shown to the user, but the "ShowPrintPopup" method acted as a factory and showed the popup both. That was clearly a violation of the SRP, so i bit the bullet and refactored the method. Now, the method only serves as factory, and it is for the client to decide when to show the View. The decorator applies the permissions on the Popup AFTER the factory method has been called, and the client never knows he's using a different instance of the IReportingService.

Let's see the before and after of our implementation:

	public class Client
	{
	public Client(IReportingService ReportingService)
	{
	ReportingService.ShowPrintView(/*SomeReport*/); //Client calls the Reporting Service and it works both as factory and showing view
	}
	}
	public interface IReport {}
	public interface IReportingService
	{
	void ShowPrintView(IReport Report);
	}
	public class ReportingService : IReportingService
	{
	public void ShowPrintView(IReport Report)
	{
	//Create and show the view
	}
	}

view raw Why is the SRP important - Before.cs hosted with ❤ by GitHub

As you can see, the client was only able to call the method. Again, the "ShowPrintPopup" does two things in this example: it creates the view and it shows it. Now let's see the after:

	public class Client
	{
	public Client(IReportingService ReportingService)
	{
	//This instance is a ReportingServiceSecurity injected with the real ReportingServices
	ReportingService.GetPrintView(/*SomeReport*/).Show(); //Client calls the Reporting Service to get an instance and is responsible for calling Show.
	}
	}
	public interface IReport {}
	public interface IPrintView
	{
	void Show();
	bool AllowExportPDF {get;set;}
	bool AllowExportWord {get;set;}
	bool AllowExportExcel {get;set;}
	}
	public interface IReportingService
	{
	IPrintView GetPrintView(IReport Report);
	}
	public class ReportingService : IReportingService
	{
	public IPrintView GetPrintView(IReport Report)
	{
	//Create the view
	}
	}
	public class ReportingServiceSecurity : IReportingService
	{
	IReportingService _ReportingService;
	public ReportingServiceSecurity(IReportingService ReportingService)
	{
	_ReportingService = ReportingService;
	}
	public IPrintView GetPrintView(IReport Report)
	{
	IPrintView View = _ReportingService.GetPrintView(Report);
	//Apply permissions
	return View;
	}
	}

view raw Why is the SRP important - After.cs hosted with ❤ by GitHub

Bottom line is: good practices are there for a reason. Had i ignored this issue and came up with another more "ugly" solution, i know i would have paid the price. Is this solution perfect? No, i know i could separate the factory logic from the service, and maybe design things in a lot of different ways. But, given the situation, i'm confident that i have a good solution. There's always pros and cons, and i try to balance them the best i can. That's a lesson for the future, i guess.