Re: Principle of Best Principles

On Mon, Nov 21, 2011 at 11:00 PM, Intransition <[e-mail]> wrote:
> As it turns out you (and others) are pretty spot on, though I'm not sure the
> n:1 relationship is necessarily the best way to think about it, it did
> provide a good starting point. But the "too loose coupling" is really the
> great point here. And that's something you don't often hear!!! We always
> here about over-coupling.

Just out of curiosity: whereabouts do you hear so often about
"over-coupling"?  One explanation for the high frequency might be that
a lot of code that gets written has too tight coupling ("spaghetti
code") - at least that's what I see in my daily work.  One reason for
that in turn might be that people do not have a clear understanding
where they are heading to with a piece of code.  Another reason might
be that the purpose of a piece of code changes over time and often
people do not go through the exercise of refactoring - either because
of laziness or - more likely in the corporate world - because they
don't get the resources (time) granted (which, btw, seems a very short
sighted strategy to me because it will come back haunt you later).

> But really it's "just right coupling" that is the real deal.

Absolutely.  It's generally easy to go to extremes.  It's much harder
to find the right middle ground.  A good solution to a technical
problem requires more work than a mediocre solution.  So chances are
that good solutions rather lie in the middle ground than at the
extremes.  You can even generalize that to other areas of life itself:

http://en.wikipedia.org/wiki/Middle_way

> So in my (real life) case I kept the coupling.
>
> However, I did end up applying the Single Responsibility Principle, and
> though it was bit difficult to work out the restructuring as first, the code
> turned out much cleaner in the end. So that pattern at least proved itself.
>
> Lessons learned.
>
> Thanks.

What a great feedback!  It's good to see how the community evolves
through collaborative learning experiences.  That's what makes this
community such a great place.

Kind regards

robert


PS: I find Meyer's book "OOSC" a great source of OO design advice -
although it is hidden in a large description of Eiffel.  The way he
dissects various aspects (e.g. inheritance) shows that he has thought
a lot about OO - and came to an understanding which is rarely equaled.

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/