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:
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:
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.
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:
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:
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.
Comments
Post a Comment