I only got to learn about SOLID about 6 or so years ago and it has drastically transformed the way I look at code and how I approach my code design. I feel that every developer should at the very least know SOLID. It's the core principles that most patterns are based on today and even if you don't know any patterns, if you've got SOLID under the belt, patterns will emerge naturally.
I found it particularly difficult to prepare for this session. Out of all the principles in SOLID, the SRP (Single Responsibility Principle) is the one that is most debated. Some find Robert C Martin's definition of it a bit too strict and I tend to agree with those people.
Part of code maintainability, along with things like loosely coupled code, reusable components, etc, is code cohesion. If your code is not easy to read and easy to follow or debug, then you've not accomplished much. Just as much time may be wasted trying to figure your code out than making redundant fixes. Ok yes, there are other things that you can do to "improve" cohesion, like proper use of namespaces, to mention one. Code comments is also a solution but lets be honest... code itself must be readable. If I'm going to have to read comments every time I need to tackle something, then it will take me ages to debug the code.
Putting that and things like proper variable naming aside, the only real way to make your code highly cohesive, is to refactor it to such an extent that it all still makes contextual sense. This is the general argument against uncle Bob's definition of the SRP. Instead of being technically pure, focus more on the context of the actual object.
You still want to follow DRY (Don't Repeat Yourself) but having a class violate the SRP by having multiple responsibilities for the sake of context is not the end of the world, I feel. It also depends on what those responsibilities are of course.
Anyways, the SRP for me is one of the most important and misunderstood principles. Your code can very easily turn into a maintenance nightmare if this principle is not implemented correctly. I always couple the SRP along with the OCP (Open/Closed Principle - will discuss this in our next session) because of the question that always pops up when I'm thinking of how far to take refactoring: What do I need to open for extension and what can I close for changes? That always guides how far I take something with the SRP. For ex, if you're writing a component that will never ever get reused and it makes to contextually keep everything together in one class, then I'll just make sure that everything is readable and logically separated enough for the key components to be testable, but that's it. Won't take it any further.
Knowing how far to take refactoring is the different between coding efficiently and running into recursive analysis cycles.
So, for those that have never dealt with the SRP, it's gonna be a little bit of a mind bend, but if you stick to the basics, you should be fine. And of course, practice practice practice.
Important things to consider when refactoring:
-refactor small bits at a time
-if you can't test the code, you've most likely sitting with a bad design
For this session, you can find the various stuff here:
Presentation: http://www.slideshare.net/DeonMeyer/code-like-a-ninja-session-2-single-responsible-principle
Code: https://github.com/sheepworx/training
Let me know what you think
</Meh>
No comments:
Post a Comment