Skip to main content

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:

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

Popular posts from this blog

From crappy to happy - refactoring untestable code - an introduction

I started testing my code automatically a couple of years in after starting my career. Working in a small company, there weren't really incentives for us to automate testing and we were not following any kind of best practices. Our way of working was to write the code, test it manually and then just Release It ™ , preferably on a Friday of course. I'm sure everyone can relate to this at some point in their career, because this is a lot more common than the Almighty Programming Gods of the Internet make us believe. I find that the amount of companies that actually bother writing tests for their production code is a fraction of the whole universe. I know some friends who work in pretty big companies with big names in the industry and even there the same mindset exists. Of course, at some point in time our code turned into a big pile of shit . Nobody really knew what was going on and where. We had quantum-level switcheroo that nobody really wanted to touch, and I suspect it i...

The repository's repository

Ever since I started delving into architecture,  and specifically service oriented architecture, there has been one matter where opinions get divided. Let me state the problem first, and then take a look at both sides of the barricade. Given that your service layer needs to access persistent storage, how do you model that layer? It is almost common knowledge what to do here: use the Repository design pattern. So we look at the pattern and decide that it seems simple enough! Let's implement the shit out of it! Now, let's say that you will use an ORM - here comes trouble. Specifically we're using EF, but we could be talking about NHibernate or really any other. The real divisive theme is this question: should you be using the repository pattern at all when you use an ORM? I'll flat out say it: I don't think you should... except with good reason. So, sharpen your swords, pray to your gods and come with me to fight this war... or maybe stay in the couch? ...

My simplest and most useful type

I have been doing some introspection on the way I write code to find ways that I need to improve. I consider this a task that one must do periodically so that we keep organized. There is a very, very simple problem that occurs in every application I know: How to return the results of an operation to the user? I've seen many implementations. Some return strings, some throw exceptions, some use out parameters, reuse the domain classes and have extra properties in there, etc. There is a myriad of ways of accomplishing this. This is the one I use. I don't like throwing exceptions. There are certainly cases where you have no choice, but I always avoid that. Throughout my architectures there is a single prevalent type that hasn't changed for years now, and I consider that a sign of stability. It is so simple, yet so useful everywhere. The name may shock you, take a look: Yes, this is it. Take a moment to compose yourself. Mind you, this is used everywhere , in every ...