Decoration vs. Module Extension

[Avdi Grimm]

When discussing Presenters, Decorators and/or DCI in Ruby, the question of traditional delegation-based object composition vs. dynamic module extension tends to come up. I wrote up some thoughts on that decision: http://avdi.org/devblog/2012/01/31/decoration-is-best-except-when-it-isnt/

I'd be interested in this group's feedback.

[Sam Livingston-Gray]

I read that this morning, and quite enjoyed it. (Discworld, HHGTG,
*and* D&D? How could I not?)

Your point about delegation missing some overrides was quite interesting.

If I may be permitted a slight digression: I've found that I really
learn a lot from seeing examples that are extremely "pure." A few
examples:

- Ryan Davis has some strong opinions about mocking and stubbing --
which, after trying out MiniTest in a small learning project, I came
to agree with, at least in part. (See:
http://confreaks.com/videos/618-cascadiaruby2011-size-doesn-t-matter
and http://www.zenspider.com/~ryan/presentations/CascadiaRubyConf_2011_-_Size_Doesn't_Matter.pdf)
- James Ladd's "East-Oriented Code" describes an approach that seems
quite radical, but when I tried it out in the aforementioned small
learning project, I found that it led me to a system that observed the
Law of Demeter even when I wasn't especially paying attention to that
principle. (See: http://jamesladdcode.com/?p=12 and
http://jamesladdcode.com/2011/08/10/east-example-code/)
- Some guy with a weird name wrote this ebook that, I thought, totally
jumped the shark at the end with some Taggable module, but even if I'm
not sufficiently convinced of its advantages to try using it in anger,
I really enjoyed seeing it.

In light of that, I wonder if someone might know of an example where
delegation's failure to jump back down the stack for overridden
behavior could be considered a feature, and not a bug?

As for modules in general...

Modules have traditionally been one of my very favorite Ruby features,
but I'm starting to regard their use (with or without the
ActiveSupport::Concern niceties) as a design smell, because they
almost always represent a way to overload an object with additional
responsibilities.

Following the link from your post to Gregory Brown's post on
connascence leads to another of Gregory's posts about SOLID. The
section on SRP is a considerably longer and better-supported version
of the same argument:
http://blog.rubybestpractices.com/posts/gregory/055-issue-23-solid-design.html

Modules make it *appear* as though you're separating concerns out into
small, narrow slices of behavior that don't interact, which can lead
to a false sense of clarity. At their best, modules are a decent stab
at the Traits approach
(http://web.cecs.pdx.edu/~black/publications/TR_CSE_02-012.pdf) -- I
still consider Enumerable a thing of beauty. Unfortunately, after six
years of coding in Ruby, I don't have any other uses of modules that I
can hold up next to Enumerable and not be embarrassed by. ;>

-Sam

[Avdi Grimm]

On Tue, Jan 31, 2012 at 2:42 PM, Sam Livingston-Gray <gee...@gmail.com> wrote:

If I may be permitted a slight digression:  I've found that I really

learn a lot from seeing examples that are extremely "pure."  A few
examples:

I'm glad someone does. I catch a lot of grief because I simplify examples in order to make the point more prominent. The complaints are usually either:

1. "That example is contrived, so your point is moot"; or
2. "That code is so simple the solution you show is obviously massive overkill"

 

--
Avdi Grimm
http://avdi.org

I only check email twice a day. to reach me sooner, go to http://awayfind.com/avdi

[Sam Livingston-Gray]

On Wed, Feb 1, 2012 at 3:20 PM, Avdi Grimm <av...@avdi.org> wrote:
> On Tue, Jan 31, 2012 at 2:42 PM, Sam Livingston-Gray <gee...@gmail.com>
> wrote:
>> If I may be permitted a slight digression:  I've found that I really
>> learn a lot from seeing examples that are extremely "pure."
>

> I'm glad someone does. I catch a lot of grief because I simplify examples in
> order to make the point more prominent. The complaints are usually either:
>
> "That example is contrived, so your point is moot"; or
> "That code is so simple the solution you show is obviously massive overkill"

Heh. I think I meant "pure" in the sense of "something a purist would
approve of", or possibly just "extreme" -- but the Taggable example at
the end definitely qualifies. It is also, however, simple enough that
the complexity of the problem domain doesn't obscure the shape of the
technical solution.

[Sammy Larbi]

On Wed, Feb 1, 2012 at 5:20 PM, Avdi Grimm <av...@avdi.org> wrote:

On Tue, Jan 31, 2012 at 2:42 PM, Sam Livingston-Gray <gee...@gmail.com> wrote:

If I may be permitted a slight digression:  I've found that I really

learn a lot from seeing examples that are extremely "pure."  A few
examples:

I'm glad someone does. I catch a lot of grief because I simplify examples in order to make the point more prominent. The complaints are usually either:

1. "That example is contrived, so your point is moot"; or
2. "That code is so simple the solution you show is obviously massive overkill"

I'm one of those people who learn better from more complex/complete examples, but I don't fault anyone for demonstrating technique like you have. I have to work harder to see how it might be used in a "real-life" scenario.

I think what you've done is more prevalent from anyone who shows how to do something (I try myself when giving instruction), and I think it probably helps more people to show it that way.

That said, I do wonder what the breakdown looks like of people who learn better through the simple-example-highlight-technique vs. complex-example-where-technique-may-get-lost ways of demonstrating things.

Sam