[rspec-users] Collection proxies need to be stubbed ?

David Chelimsky dchelimsky at gmail.com
Sun Jan 21 17:14:37 EST 2007

On 1/21/07, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> Francois Beausoleil wrote:
> >
> > Adding #active_projects on User leads to a kind of namespace
> > pollution, no ?  Really, who knows what projects are active ?  The
> > Project class, or the User ?
> This seems to be a basic conflict between "Tell, don't ask" and
> domain-driven design.  DDD, as I understand it, says the Project class
> should encapsulate all knowledge about projects; TDA says we shouldn't
> ask for the project proxy.  Yes?

TDA says we shouldn't even ask the User for its Projects. It's the Law
of Demeter that says we shouldn't ask the User for it's Projects and
THEN ask the Projects whether they are active.

Just because rails makes it easy doesn't make it a good design choice.
It really depends on context. If your app is never going to change
requirements, then the problems associated with violations of OO
design principles don't really matter. They are all about writing
maintainable software.

I'm serious here - I don't mean to patronize. There are times when the
application you're writing will have simple requirements and a short
potential life-span. In those cases, the costs of heeding to design
principles might outweigh the benefits of a flexible design.

That said, imagine that somewhere down the line the requirements
change such that User knows its Projects through some middle man, like
a ProjectManager. Now you'd have to change all the places in the code
that say "user.projects.active" would have to change to

Of course at that point you could change #projects to delegate to
project_manager.projects, so clients of User wouldn't have to change,
but you see the point.

So I'd prefer to not advertise how the User keeps its Projects.

But that's me. 2 cents worth.

> Jay
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list