[LRUG] Evaluating Hexagonal/SOLID Principles in Rails

[Paul Mucur]

Good morning all,

During my commute this morning, I finally had an opportunity to listen
to the Ruby Rogues' interview with David Heinemeier Hansson [0] and I
wanted to stir up some discussion on the list regarding some of what
DHH said re the recent interest in "Hexagonal Rails" [1], Dependency
Inversion [2], etc. within the community.

At the risk of paraphrasing him incorrectly, DHH seems highly
sceptical of any improvement offered by tools such as Objectify [3] or
even design principles such as SRP or Law of Demeter as he uses only
one measure of quality: whether the code looks better with or without
the tool/principle applied.

Of course, defining "looks better" is highly subjective (and Tom
Stuart posited an extremely interesting theory during his talk [2]
that the pursuit of "beautiful code" in Ruby is damaging) but I think
there is an uncomfortable truth buried in here: that maybe we do need
to prove that code after redesign/refactor is *measurably* better than
the old. I fear that simply stating "it's more maintainable" without
demonstrating the fact is too vague and can be dismissed, as DHH puts
it, as "fortune telling".

Yesterday, I experimented with refactoring a controller ala Matt Wynne
and Steve Tooke's example [1] at our last meeting (but with some
mistakes as you'll see). By the end of the first pass, I had initially
pushed some of the complexity into Responders rather than leaving it
all in the controller. At first, this seemed like an improvement
because the controller was decidedly skinnier but it had lost
significant meaning: I had simply pushed the code into another file,
thereby hiding it rather than simplifying the design.

e.g.

    require_relative "../responders/article_responder"

    class ArticlesController < ApplicationController
      respond_to :html, :json

      def index
        respond_with(current_user, responder: ArticleResponder)
      end
    end

Worse still, the Responder inherited from ActionController::Responder
so it offered no decoupling from Rails at all. I had obviously lost
sight of what I was originally trying to do. This made me wonder; what
*real* metrics can we use to both steer and measure the quality of our
designs? To simply state "looser coupling" or "adherence to the Single
Responsibility Principle" seems to be arguing at the wrong level:
these are both purportedly qualities of better code but what do they
truly enable? An obvious and practical answer might be "easier major
Rails upgrades" but I'd be keen to hear your thoughts.

Don't misunderstand me: I believe that separating your application's
core logic from your particular framework is a Good Thing but I feel
like we need more worked examples exploring the realities of creating
applications in this style such as James Hunt's recent "Building a
Rails app without Rails" [4].

I grow increasingly convinced that these principles are not something
that Rails or even Objectify can help us with as the key is to change
how we should build and design our applications *regardless of
framework*. This is particularly evident to me having co-authored
Proffer [5] which was an attempt to mitigate a bad practice with
tools. Perhaps the best thing we can do as a community is not to
constrain with software but to focus on *education* and examples?

-- mudge

[0]: http://rubyrogues.com/056-rr-david-heinemeier-hansson/
[1]: http://skillsmatter.com/podcast/ajax-ria/hexagonal-rails
[2]: http://skillsmatter.com/podcast/ajax-ria/dependency-injection/js-4123
[3]: http://jamesgolick.com/2012/5/22/objectify-a-better-way-to-build-rails-applications.html
[4]: http://ohthatjames.github.com/2012/06/17/rails-without-rails/
[5]: https://github.com/hudge/proffer