
Pattern vision - fogus
http://37signals.com/svn/posts/3341-pattern-vision
======
pelle
I see a lot of current libraries in the Ruby world taking this Patterns are
law approach.

Particularly the Law of Demeter and the Single Responsibility Principle are
frequent offenders.

You end up with something that could have been handled in one or two small
classes and/or Concerns split up over 30 or so files neatly organized in a
module hierarchy.

End result is that every single file has a single responsibility yet it's
extremely difficult to see whats going on.

Rails 3 I think unintentionally started this. Through it's use of Concerns.
This is good in a very large framework such as Rails and when the Concerns
like in Rails contain a decent chunk of related code grouped together in one
readable chunk.

I use Concerns within my own apps as well to maintain readable re useable code
that can be used in multiple models.

If you have 20 Concerns each containing one or two methods split all over the
file system it's difficult to maintain, but even harder to understand.

The Law of Demeter has also brought us ActiveModel wrapper classes that wrap
all of this code together and when you add a column to the underlying table
you can't use it with the wrapper class since it's not a real AR model. So you
now have to fork the library or write your own models.

(edited to use the word Concern instead of the more generic Mixins)

~~~
stcredzero
_> If you have 20 mixins each containing one or two methods split all over the
file system it's difficult to maintain, but even harder to understand._

This is a consequence of the source code persistence mechanism being also used
as a browsing and organization system. It's an impedance mismatch problem only
Smalltalk tried to tackle in the past. Code Bubbles and Light Table have
mentioned it more recently.

What if one could tag code and easily browse it by tag?

~~~
pelle
That is true, but it is still the reality of how we code Ruby today. (also
most editors are pretty good at navigating this)

One of the original beauties of Rails was it's pragmatic approach. It took a
couple of key patterns and bent it into a less pure yet easy to use way of
writing maintainable code.

I'd argue that the directory structure and conventions behind it was DHH's
main innovation here. Of course Rails own code base was quite ugly out of
necessity before the 3.0 rewrite to handle this.

I think the current trend to use patterns blindly comes from the fact that
there are so many large Rails legacy apps now. We need better ways of
organizing the code. Yet we shouldn't break what made Rails good in the first
place or we end up with the Ruby equivalent of EJB's.

~~~
stcredzero
So, we should just stick with files, or else we get EJBs? Sorry, it doesn't
follow.

~~~
pelle
Thats not what I'm saying.

If we are in the business of writing Rails apps and not innovative new IDE's
we need to write code in a way that works with our existing tool belt.

If we start blindly following patterns without being pragmatic about our
current tool belt we may very well see the ruby equivalent of EJB's.

~~~
stcredzero
If that were the only proper strategy, then why wouldn't we be looking at even
more optimal codes to fit on punch cards?

------
raganwald
I saw a tweet that sums it up: "Refactoring to patterns is far more important
than designing with patterns."

~~~
stcredzero
DRY is all you need in a language with a full implementation of blocks.

------
mcgwiz
tl;dr - patterns are seductive, and without understanding yagni, they strongly
tend to be counterproductive.

