Menu
I basically want to get an idea of the percentage of people who think it's reasonable to use the Single Responsibility Principle in real-world code and how many actually do. In Podcast #38 Joel talks about how useless this OOP principle is the real world; and further that this demonstrates how people like Uncle Bob have likely not written non-trivial systems.
I've personally written or played a big role in a few software projects but have only now come across this pattern in my young career. I love the sound of this principle and would really like to start using it. I found Joel's argument in the podcast quite weak (as did others if you continue on to read the blog comments here). But, is there any truth in it?
What does the community think?
851
For example, if we have a class that we change a lot, and for different reasons, then this class should be broken down into more classes, each handling a single concern.
The argument for the single responsibility principle is relatively simple: it makes your software easier to implement and prevents unexpected side-effects of future changes.
A class should have only one reason to change. A common misconception about this principle is that people think it means that a class should do only one thing. This is not the case: a class can do multiple things. If not, you'd end up with classes that only have a single public method.
Benefits of Single Responsibility Principle When an application has multiple classes, each of them following this principle, then the applicable becomes more maintainable, easier to understand. The code quality of the application is better, thereby having fewer defects.
I have had some experience applying SOLID principles and my experience has been mainly good. I also heard the podcast and it sounds like neither Jeff nor Joel has tried any of the things they're talking about long enough to really asses the benefits. The main argument against is as usually "you write more code". If I look at what I do I write 10 maybe 20% more code (usually interface definitions) but because everything is highly decoupled it's far more maintainable. I hardly ever have situations where changes in one part of my application break other parts. So the 20% extra code i have to maintain pays for itself.
Jeff also missed the point on code quality. He doesnt see code quality as a great benefit for the customer. And he's right, the customer doesn't care. The customer does care about having new features implemented quickly and that's where code quality comes in. I've found that the investment of keeping the quality of code as high as possible has always paid itself back within a few months. High quality = low maintenance.
I do agree with them that like anything you have to be pragmatic about these things. If you need to deliver something then go ahead and do it fast and dirty. But clean up afterwards.
129
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
