[rspec-users] Associations should be private
lattam at mac.com
Wed Oct 1 14:29:54 EDT 2008
The point is to never assume the structure of another object, but to
let it decide that. So you never get A.B.C you always use a method on
A to do the work. You get a lot more methods on A but the structure
underneath can change without a ripple effect. For example if you had
2 associations that got merged into one you can still support the same
method interface and then filter the one association to appear to be
2. Or you can merge 2 into what appears to be one, etc. Using
plugins that do this too simply removes some of the value. If they
always map the underlying structure you have not gained much. But, if
you can specify the intended interface and then map that to the
underlying structure you have gained much more. That of course
requires a more sophisticated (complex) plug-in and some added work to
explicitly define the interface. The whole convention over
configuration means that the underlying structure tends to be exposed
more than good software engineering practice would advise, but it
works because most of the time the cost to fix a change is actually
lower in Ruby than the cost of preventing the change.
On Oct 1, 2008, at 7:54 AM, Mark Wilden wrote:
> On Wed, Oct 1, 2008 at 6:11 AM, David Chelimsky
> <dchelimsky at gmail.com> wrote:
> It's been a while since I've taken a look at it, but Luke Redpath has
> a plugin called Demeter's Revenge
> that actually manages this all for you by adding methods like
> team.add_player that wrap chains like team.players.add. It's a year
> old and I don't know if it works w/ the latest rails updates or not.
> See, this is what I don't get about Demeter. By adding delegators,
> you might trick someone into thinking that you're not playing with
> other objects' parts, but really you still are. Does Demeter just
> mean mechanically adding a level of indirection?
> For example, in the case under discussion, even with Demetering,
> you're _still_ going to get back a proxy object, and end up with the
> same problem, aren't you?
> P.S. Of course, controlling access to data (especially changing it)
> can often be a Good Thing. But that's just a general principle and
> applies to your own data as well as to your data's data's data.
> Nothing Demetery there.
> rspec-users mailing list
> rspec-users at rubyforge.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rspec-users