Hacker News new | comments | show | ask | jobs | submit login
Pattern vision (37signals.com)
43 points by fogus 1581 days ago | hide | past | web | 9 comments | favorite

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)

> 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?

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.

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

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.

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

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

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

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

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact