Channels ▼

Arnon Rotem-Gal-Oz

Dr. Dobb's Bloggers

Building on a SOLID foundation

February 15, 2009

Returning from a short blogging vacation (both personal and work related) I found my RSS reader is getting filled with posts relating to "Uncle Bob vs. Joal & Jeff or the case of the SOLID principles (OO principles by various people including Uncle Bob himself - you can also read the "OO Primer" paper (pdf/ppt) I worte on these and few related principles).

Codeclimber has the complete timeline, but in essence, Unclue bob talked about the SOLID principles in a Hanselminutes podcast; Joel Spolsky commented that "quality doesn't matter that much" on his and Jeff's StackOverflow podcast, which was followed by a few blog posts on both side like Uncle Bob's "Open letter to Joel Spolsky and Jeff Atwood" and Jeff Atwood's "The Ferengi Programmer".

I don't know Uncle Bob personally (I've seen him talk a couple of times and I read his blog/papers), so I might be off here. However (to me) Uncle bob usually comes off  as  being too religious about following practices to the letter. e.g. see the debate  between Uncle Bob and Jim Coplien on TDD where Bob says "nowadays it is irresponsible for a developer to ship a line of code he has not executed in a unit test."

Nevertheless, I am fully with Unclue Bob on this one. I especially like the following qoute from his "Getting a SOLID start"

"The SOLID principles are not rules. They are not laws. They are not perfect truths. The are statements on the order of “An apple a day keeps the doctor away.” This is a good principle, it is good advice, but it’s not a pure truth, nor is it a rule.

The principles are mental cubby-holes. They give a name to a concept so that you can talk and reason about that concept. They provide a place to hang the feelings we have about good and bad code. They attempt to categorize those feelings into concrete advice. In that sense, the principles are a kind of anodyne. Given some code or design that you feel bad about, you may be able to find a principle that explains that bad feeling and advises you about how to feel better."

You see, the point about these OO principles (and patterns and even so called "best practices") are an attempt to distill experience. Assuming these principles are worth anything (and the SOLID ones do) - You can either  ignore that knowledge and learn these lessons the hard way, i.e. through your mistakes or internalize them and apply them.

How do you apply principles - by applying critical thinking. I wrote here before that I don't like the term "best practices" since it implies you don't have to think. Sorry, being a developer means you have to think, deal with it. There's no "deus ex machina" - it is all up to you.
Any good idea can be abused, e.g. let's look at the Single Responsibility Principle. SRP helps bring cohesion into classes by  lowering the "reasons to change. It is very easy to apply it ad absurdum and get a single method classes that really only do one thing but that's not the way to go.
The thinking part means that when we implement some class, and we happen to know about SRP, we can say to ourselves, hey this looks like an SRP violation. Why am i doing this? Do I have a good reason for that etc. knowledge of principles and patterns promote making your design decisions explicit and thus having you control the design (and architecture) rather than the other way around.

One claim I read is that principles such as SOLID preach to the choir. The so called "20% of developers" who already read blogs, enrich themselves and generally know what they are talking about. Well, I don't know, but the way I see it, not all those developers are black belt gurus who feel good design by the direction of the wind or get perfect code by mumbling a few incantations. I know I am not one. That means I am always learning. Ok, so I already know about SOLID and a couple of other nifty patterns so I need to learn other stuff like good principles for functional programming or whatnot . If you are starting out on OOP though, I suggest you build yourself on a SOLID foundation and go form there

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.