Rules, guidelines, and principles are gems of distilled experience that should be studied and respected. But they’re never a substute for thinking critically about your work.
I’ve always seen these things as tools for thinking critically about your work. They are all a little too abstract to try to apply directly without any real thought, anyway.
They also provide a common vocabulary for discussing code, so you can say things like this class doesn’t follow the single responsibility principle very well and other people will (hopefully) understand what that means.
The principles of SOLID or any big M Methodology are intended to prevent people from making mistakes.
Really? Have you read them?
Seems to me that SOLID is all about fostering agility in large OO code-bases (not excluding small of course). Agility is coding is something that Paul Graham has preached over and over.
So what you’re saying, Jeff, is the opposite of what Martin suggests; don’t use any rules v. use rules. So then your rule is to have no rules. In the end, you’re both suggesting following a rule, they’re just different rules.
How would it be different if SOLID wasn’t about rules, but about principles? Oh, wait, it is.
How would it be if there were demonstrably good principles that, by our understanding and awareness of when and how to apply them, made it possible for us to write software that worked better, got released faster, failed less frequently, cost less and made our customers happier?
I’m just askin’
I’ve only been writing software for 30 years or so*, and my understanding of SOLID doesn’t get much past SOL (and I’m still a bit shakey on L) but what I do understand of it definitely helps me deliver satisfied users better than before. And isn’t that really a large part of what it’s all about?
(* I’m not bitter, you understand, just old and a little tired.)
Uncle Bob had some valid points, but then he turned to outright insults and lost all credibility.
@Just wow
It doesn’t. The point is that sometimes such rules are excessive and unnecessary. It would literally take years to refactor my current projects to fit these principles. The projects are working and don’t have any issues. The company I work for would gain absolutely nothing, aside from maybe one problem down the road may take slightly less time to debug. This would be a terrible return on investment.
Jeff you make a good argument by backing it with the Dreyfus model but these rules that Uncle Bob advocates are really targeted at beginners and advanced beginners to practice so we can have a bare minimum of software quality. So I believe the SOLID principles are perfectly valid for being introduced to all members of these groups. As they progress to competent and expert levels it is ok for them to make more decisions about what works and what doesn’t from the SOLID principles as long as they don’t make negative progress. It would at the very least reduce the submissions to TheDailyWTF if everyone had a grip of these basic software design principles.
So the design that is produced by inexperienced people working to a tight deadline is better than that of one done to SOLID principles?
A design produced by inexperienced people trying to adhere to SOLID principles won’t get done on deadline, or at all. If it does ostensibly get done, it’ll be a pile of crap.
The point is, trying to fit a project into the rules, when the people don’t have the experience to know how to use the rules, distracts from their actual responsibility: getting the job done.
Again, it’s up to those who are more experienced and in charge, to manage things according to whatever principles apply, based on their experienced judgement. At that level, the rules are wise and productive.
It’s like the dichotomy between a coach and a team. Good coaches have much deeper understanding of the sport than their players. But they DON’T try to jam that knowledge into the players and force them to follow it. That overloads the players, getting them so distracted and confused that they play worse. Instead, the good coach applies his experience on a play-by-play basis, with specific instructions to the players – not general rules.
It would literally take years to refactor my current projects to fit these principles. The projects are working and don’t have any issues. The company I work for would gain absolutely nothing, aside from maybe one problem down the road may take slightly less time to debug. This would be a terrible return on investment.
As long as you stay with that company forever, then you are probably correct. You’ve got the system figured out, so why would you ever want to refactor to the SOLID principles? And then if you leave that company, who cares anyway?
Could someone who actually agrees with this forum post, please give a non-trivial example of how not adhering to any of the SOLID principles leads to a better design?
You responded with:
Yes: when a challenging project with specific requirements needs to be completed on deadline by a team of limited experience. In other words, the real world.
Sorry, your answer just doesn’t make any sense. You’ve not shown that ignoring SOLID has produced a better design, just that in the real world often projects are designed ad hoc. What have you proven?
Let’s face it, it’s not like learning the individual principles of SOLID is difficult, they’re easy simple guidelines. Let’s take your real world example for a second, if a manager spent a grand total of 5 minutes with his/her team of limited experience programmers he/she could easily teach them one of the principles, say Dependency Injection, how is that a hard?
Maybe you aren’t aware that the majority of time spent on a project is maintenance, including something as simple and trivial as Dependency Injection goes a long way in maintaining the testability of existing code.
Should every application follow every single rule of programming? No, of course not, especially if you are building a small application of limited use. But saying be your own unique snowflake, don’t follow the rules has resulted in more bad code than good code, I can guarentee you that.
The point is, trying to fit a project into the rules, when the people don’t have the experience to know how to use the rules, distracts from their actual responsibility: getting the job done.
You keep saying this. Presumably we are minimally talking about recent C.S. grads. What makes you think that they would not be able to understand SOLID principles? Nothing in them that I have read requires 30 years of experience to wrap my head around.
-m
I guess that’s why they’re principles and not laws. It’s up to you the developer to decide, which of those principles may need to be sacrificed dependent upon what the objectives and more importantly the constraints of the project are.
If you set out to adhere to as many as possible then prioritise those, which are most useful to your business / problem domain.
Most importantly, once you’ve decided, which SOLID principles to follow, remain consistent.
SOLID principles are just a collective of sound OO advice collated by an articulate, talented and busy engineer over his career. I for one am glad he took the effort to write down his and other peoples observations and to come up with a mnemonic for us to remember them by.
I look forward to his guest appearance on your podcast Jeff.
@Fogus
Seems to me that SOLID is all about fostering agility in large OO code-bases (not excluding small of course). Agility is coding is something that Paul Graham has preached over and over.
Paul Graham doesn’t think much of OOP in general. I think there are five reasons people like object-oriented programming, and three and a half of them are bad http://www.paulgraham.com/noop.html
It’s like the dichotomy between a coach and a team. Good coaches have much deeper understanding of the sport than their players. But they DON’T try to jam that knowledge into the players and force them to follow it. That overloads the players, getting them so distracted and confused that they play worse. Instead, the good coach applies his experience on a play-by-play basis, with specific instructions to the players – not general rules.
A good coach is constantly teaching his players and doing whatever he can do get the best performance possible out of them, so I’m really not sure where you are going with this analogy.
Let’s put it this way, when I coached baseball years ago, if I noticed that a batter was dipping his back shoulder or was pulling off the ball, I’d teach him not to, and more importantly, I’d explain to him why it is bad. That is part of my job as a coach, to help him become a better player so next time he’s up, he won’t make the same mistakes.
Coaching on a play-by-play basis is just micormanagement to the nth degree, and in any sort of long run will fail. If a ball is hit to deep right field, my right fielder needs to know where the cut off man is going to be standing and the cut off man needs to know that with a man on second, he’s going to have to get that ball to home ASAP to have a chance to get that runner at the plate. Coaching this on the fly will result in failure 99% of the time, having your players know what to do at least gives you a chance for success.
An IT manager’s job is very similar. If a programmer has limited experience, you teach them how to code the right way. It might not help you on a current project that is already a big ball of mud, but it will help on future projects. That is what teaching (or coaching) is all about.
