Når skal man bruke SOLID prinsippene?
- Sunday, May 3rd, 2009
- Skriv en kommentar
SOLID er benevnelsen på fem prisnipper innenfor objektorientert softwaredesign som vi har hørt mye om i løpet av den siste tiden. Blant annet holdt Mark Nijhof et innlegg på NNUG Bergen om SOLID i januar i år. Foredraget finnes også i blogpost-format her.
Siden det foredraget har jeg forsøkt å lære meg disse prinsippene, og brukt dem etter beste evne. Akkurat nå leser jeg Robert C. Martin’s Agile Prinsiples, Patterns, and Practices in C#, og da går det plutselig opp for meg at selv om mange har forsøkt å lære meg prinsippene, så er det ingen som sålangt har fortalt meg hvordan man skal bruke dem.
I boken sier Onkel Bob Martin at man skal bruke prinsippene når de trengs. Unødvendig bruk fører bare til unøvdendig kompleksitet. Jeg føler dette er et viktig poeng å få frem.
Ta for eksempel Single Responsibility Prinsiple (SRP). Dette prinsippet sier at en klasse kun skal ha ett ansvar, og ansvar defineres som én grunn til å endres. Men en grunn til å endres er kun en grunn til å endres om den endringen faktisk inntreffer. Onkel Bob sier at det er ikke lurt å innføre SRP - eller noe annet OO-prinsipp for den saks skyld - uten at man har symtomer som kan løses med prinsippet.
Dvs. at man ikke splitter opp en klasse i flere klasser basert på ansvarsområder før man får behov for å endre klassen. Når endringen kommer, og endringen kun gjelder for ett av ansvarsområdene, kan man bruke SRP og splitte ut det ansvarsområdet som endres til en ny klasse.
“Agile teams apply principles only to solve smells; they don’t apply principles when there are no smells. It would be a mistake to unconditionally confirm to a principle just because it is a principle. The principles are there to help us eliminate bad smells. They are not a perfume to be liberally scattered all over the system. Over-confirmance to the principles leads to the design smell of needless complexity.”
Knagger: Agile, SOLID, Robert C.+Martin, Pattern
Kategorier: Softwareutvikling, OO-design/clean code.
RSS feed for kommentarene.
Tilbaketråkk.
May 3rd, 2009 at 8:26 pm
Ok I’ll bite.
I believe that most developers ‘really’ don’t need to worry about following to many principles, usually it is the other way around. Also there are so many more principles than just the 5 SOLID principles, so I am absolutely not saying you should always follow everything, that is not even possible (they often contradict each other). But applying the SOLID principles is something that I believe you should just do, especially OCP, DIP and SRP.
Of course there will be exceptions, “the exception confirms the rule” right? Also there are different gradations of applying the principles, especially with SRP. You can absolutely go crazy with defining a single responsibility, don’t do that. But if a class is doing it’s own data access, logging and order tracking then I think it does to much, three classes there for sure.
And you know what the beauty of this all is that it helps you on all fronts, there are many benefits from applying proper design principles: Testability, Re-usability, Clear intend and Easier Maintainable.
P.s thanks for the link, and sorry for the non Norwegian reply
-Mark
May 3rd, 2009 at 9:02 pm
Despite what you are saying - and I believe you are correct about most of it - the realization I made before I wrote this article really made it clear to me how it all fits together: The principles, the pattern, TDD, refactoring, and agile design and coding in general.
You don’t write code without a test. You don’t refactor without a need. You don’t apply the patterns without a violation to a principle that you have discovered through some change you had to do to the code because of a test.
But since developers usually apply too few of the principles, I understand why this hasn’t been the focus in the lectures and articles I’ve seen so far.
May 3rd, 2009 at 9:19 pm
Well when doing TDD it becomes very cumbersome to not apply SOLID, then you suddenly have so much setup in your tests and external dependencies that your head explodes
So if you are doing proper TDD then I don’t think you have a problem discovering when to and when not to apply the right principles. TDD and SOLID go hand in hand.
Btw I agree with the last sentence 1000% and that is the reason why I would not easily write a post suggesting that developers perhaps should not follow the principles. I believe when the developers are mature enough to see that violation is better then following a principle that then they are mature enough to decide not to follow it. The problem usually is that principles are left behind because the developer doesn’t really understand it.
May 3rd, 2009 at 9:30 pm
I totally agree on following principles (or patterns) for their own sake is a bad thing. It creates accidental complexity, and that’s the kind of complexity we can best live without.
On the other hand I find some principles fundamental. I am passionate about readable and maintainable code. I have seen quite a lot of the opposite in my years as a developer, and know how hard unreadable code is to maintain. Some principles have to be applied to some degree at all times in order to write understandable code.
Creating classes with several distinct and different responsibilities often creates a distinct smell of unreadableness. To prevent this smell Robert Martin talks about, among other things, SRP. I like to talk about cohesion. Cohesion is about placing logic where it belongs, and being able to find it when you need it. I think SRP is a great principle to get higher cohesion. I split my classes if they are getting hard to understand, and they tend to be hard to understand when they have too many responsibilities.
When it comes to the Solid-principles:
The problem with the Solid-principles these days is that people seem to think that those are the five only true principles of design. First, There are many others and IMHO also a few more fundamental and important principles than the Solid-principles. Second, I do not actually find all five of the Solid-principles that important in my daily work. I love SRP for maintainability (and I focus on cohesion all day long). I use DIP daily for testing. Sometimes, when I feel really clever, I use OCP. But when it comes to LSP I think a more important principle is “Be very skeptical of inheritance all together”.
- Tore Vestues
May 3rd, 2009 at 10:46 pm
Yes, yes, we agree. I think maybe I just reached that maturity level, and I just wanted to shout it to the world
Let’s hope my readers also read the comments.. I wouldn’t want my post to make people stop applying good design principles. As with most techniques, especially so within agile, one should apply them fully to start with - the way the masters describe them based on their experiences - and then later figure out as one go what works best for oneself in specific cases.