
The SOLID principles of object-oriented design - gurdo
http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
======
juliangamble
There is a fantastic talk by Kevlin Henney where he deconstructs the SOLID
principles as each being either misunderstood when they were written - or
frequently misunderstood after. It was done here:

[http://scottishdevelopers.com/tag/solid/](http://scottishdevelopers.com/tag/solid/)

[http://sydney.yowconference.com.au/](http://sydney.yowconference.com.au/)

I won't spoil it by writing all the points here - just some pearls.

* The Open/Closed principle is redundant because it is already covered by the Liskov substitution principle.

* Bob Martin's view of the Dependency Inversion principle is in fact the Single Responsibility principle.

He suggests 5 more principles - but I won't spoil it by listing them here. Go
see it!

~~~
PythonicAlpha
Since there seams to be no online video (yet), could you please list the
principles added?

Also, not everybody has the possibility to visit a conference in Australia.

~~~
route66
A bit meager, but it could be FLUID:
[http://www.slideshare.net/anoras/ndc-2011-the-fluid-
principl...](http://www.slideshare.net/anoras/ndc-2011-the-fluid-principles)
(same author)

~~~
amouat
Yes, it was. I felt the critique of SOLID was much more interesting than FLUID
though (which was a bit tongue in cheek).

------
programminggeek
A lot of programmers don't like/know/care about SOLID or good code
design/architecture and also end up complaining when their codebase is a big,
huge mess. Often times, just following good OOP principles (and some FP
principles) makes it easy to clean up most messes.

The biggest thing I think many programmers suffer from is wanting to have too
few objects with big, ugly methods inside.

More objects, fewer methods, smaller methods is often the answer to managing
complexity, but it seems like humans don't like appropriately recognizing the
complexity of the problems they are working with, even when confronted with
the mess they make to solve them.

~~~
nlawalker
This is really well put. I'm an MS-stack enterprise dev and I frequently see
less-experienced developers avoid creating new classes like the plague. I see
it in older code of my own as well. I think there are two reasons behind it:
the hesitation to "recognize the complexity of the problems they are working
with," as you put it, and the incredibly misguided drive towards "code reuse."

My intuition is that in the junior-developer brain, a problem that's big
enough to justify using design patterns and SOLID code is a _really scary
thing_ that's simply going to take more time than they have. They aren't
comfortable with the idea that they can't contain the whole problem in their
heads and inside just one or two files, so rather than breaking the problem
apart so they can work on one piece at a time, they pick a part of the problem
they can start with (usually something involving manipulating strings or very
simple models... something that's simple to solve with a couple of methods)
and "organically" grow it into more and more methods and shared state until
it's bigger and scarier than the problem they started out with!

I've watched people's eyes light up with anxiety as they are introduced to a
big and complex but well organized and decoupled solution that contains a lot
of classes... the immediate reaction is "What a mess! There are so many
files!" Their first instinct is to want to combine things together, thinking
that it would reduce complexity or produce some kind of "savings." They will
choose tight coupling over "more code" every time, which is ironic because as
soon as a problem caused by the tight coupling crops up, the first instinct is
to liberally apply more code until the problem is solved.

------
discreteevent
" It is typically used with test-driven development".

Talk about creating confusion in the mind of the reader. They might have
applied some of the sold principles to this article and separated out this
completely orthogonal concern. This is what annoys me about Wikipedia
sometimes. It's full of "editors" hijacking articles to propagate their
manifesto of the week instead of just sticking to the subject.

~~~
jebus989
If only there were some way to rectify these issues

~~~
Bahamut
If that was sarcasm directed at him with the implication that he should try to
fix it by editing it himself, I'm not sure how much experience you've had
trying to edit a Wikipedia article. It can be a horrid experience.

~~~
jebus989
Search my username on en.wiki :)

------
PythonicAlpha
These principles taught me to think in object oriented ways.

Object orientation is a black box to many and many people think they program
object orientated, only because they program in Java or C#. But that's not
true. Object Orientation is about program architecture. Learning OO-Pattern is
essential for this task and to know the guiding principles of good
architectures. Start SOLID and you are save.

------
platz
[http://codeofrob.com/entries/my-relationship-with-solid---
th...](http://codeofrob.com/entries/my-relationship-with-solid---the-
big-o.html)

Interesting take on the open closed principle

