[LRUG] Evaluating Hexagonal/SOLID Principles in Rails

[Tom Stuart]

Hi,

On 19 Jun 2012, at 10:08, Paul Mucur wrote:
> 
> 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)

I just noticed that I was mentioned in this mail (and thanks so much for the kind words about my hand-waving, Mudge), so I thought I'd offer some comments by way of further clarification.

What I'm driving at is this: sometimes, in order to achieve a better*-designed system, we require some level of indirection. In the specific case of inverting dependencies, this means going from (contrived, nonsensical) e.g.:

def foo
  FooDooer.new.something(params)
end

to something like:

def foo
  foo_dooer.new.something(params)
end

This dependency is inverted; foo_dooer can be any object responding to the `something` method call**, which means it can be changed for another implementation without altering the class calling on it. This is better, for some values of better, when that extensibility is needed. But the cost is that we can no longer rely on a surface reading of this code to know what object(s) in the production system are actually receiving the `something` call. This makes our code less easy to understand, at first sight. So by DHH's metric, the code is less well-designed.

My point is counter to his: in all my time working as a Java developer with complex frameworks like Spring, Hibernate, Mockito, I can't recall a single instance of needing to read their source code to make them behave in different ways, and I suspect this is because Java libraries tend, for various reasons, to be developed with extensibility via dependency inversion - as opposed to surface readability - in mind far more than Ruby libraries. But this is perceptual, anecdotal, and controversial. I also accept that a lot of Java code suffers from the opposite problem: taking the SOLID principles to ludicrous lengths so that it's a PITA to get anything done. See also: IO in Java 5.

* By which I mean, here: more resilient to future changes without modifications to the existing code. You may disagree with whether that's a desirable trait, but it's supposed to be one of the benefits of object-oriented programming.
** Please forgive my total lack of effort to come up with decent names. It's Saturday.

> Perhaps the best thing we can do as a community is not to
> constrain with software but to focus on *education* and examples?

Just wanted to chime in with some other commenters on this point, as a postscript, and say that I totally agree that there is no substitute for experience and discretion. Principles like SOLID, GRASP, etc., can only ever be guiding principles and/or learning tools on the way to the kind of intuition about design that I think we all hope to achieve.

Cheers,

T