From: Robert Klemme <shortcutter@...>
Date: 2007-11-24T18:15:25+09:00
Subject: Re: Composition: Build objects from other objects

2007/11/24, Thufir <hawat.thufir@gmail.com>:
> On Sat, 24 Nov 2007 09:57:42 +0900, Raul Parolari wrote:
>
> > However, beware that this kind of information is useful and 'dangerous'
> > at the same time if taken literally; eg, the example it gives of a
> > Module hardcoding the class name (that is using it) is a bit.. eery
> > (although I understand that he is just trying to show the mechanics of
> > interaction module-class).
> >
> > In Ruby, a Module of course has no preconceived notion of the classes
> > using it; but, at the same time, if it needs to 'talk' to the class
> > using it, it can (see the humble Enumerable module; you write a class
> > including it, you define 'each', and suddenly.. you get a bounty of
> > methods free; the module is in fact calling your 'each').
>
>
> Thank you for the heads up, definitely something for me to come back to :)

Although I am a bit late into the discussion here are some points
where more discussion of topics like this can be found. This is really
about design patterns (as has been mentioned already).

First of all there is - of course - the famous book:
http://www.aw-bc.com/catalog/academic/product/0,1144,0201633612,00.html

Then there is the "Portland Pattern Repository"
http://c2.com/cgi/wiki?PatternIndex

Wikipedia also has some useful bits
http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29

A personal remark: sometimes I see it as a danger that delegation is
so easy in Ruby.  The downside is that if you delegate *all* the
methods of a contained object you will completely clutter the outer
class's interface and you overly increase the dependency between the
two.  Sometimes this is just what you want (because for example you
hide the contained object completely from the outside) but at other
times you just create unnecessary complexity.

Kind regards

robert

-- 
use.inject do |as, often| as.you_can - without end