[LRUG] Evaluating Hexagonal/SOLID Principles in Rails

[stephen bartholomew]

DHH is sceptical about many things :)

Thing is, I've never seen these things as rules and 'constraints'.

If you see things as guiding principals when you're refactoring code,
they'll make a lot more sense.  If you're just moving something to another
file for the sake of it, it's pointless - "it had lost significant meaning:
I had simply pushed the code into another file" was the most telling thing
you said.

I try and code by a few principals:

1. Code must communicate - objects should have some role in your domain &
methods should describe specific interactions
2. Don't dig into object hierarchies - interact via top-level interfaces
3. Apply these principals while refactoring - don't try and imagine how
everything needs to fit together

Patterns in these cases become tools for achieving this - not some big law
or constraint.

Some folks have taken this to it's logical conclusion - start with a single
ruby file and only add complexity as the features/refactoring demands.
 This is great, but you can still apply these principals when writing a
Rails app - and you'll be really thankful when it grows to significant size.

Examples etc are sometimes hard because they just look trivial but I look
back at 6 years of legacy Rails that I wrote - and are still active
development - and these things just scream out.

Steve

On Tue, Jun 19, 2012 at 10:08 AM, Paul Mucur <mudge at mudge.name> wrote:

> 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
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20120619/6675407e/attachment.html>