The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Except that in Ruby, class methods are NOT static calls, they are dynamic, so they're inherited by subclasses, and they can be mixed in from other modules. The coupling is in fact quite loose.

I don't know ruby, so I may be missing a point here, but is a class an object in ruby ? If not, how can you pass the class to a subroutine ?

Originally Posted by 33degrees

In any case, it's possible to have your cake and eat it, too. Ergo:

You lost me completely there ?

Edit:

Ah - I get it. You're suggesting to have a separate finder, but to let the activerecord serve as a decorator over it, so that user can decide which approach to use ?
That's a pretty good compromise actually.

This is how I've been using find*() methods for the past 8 months. A Finder instance is responsible for all SELECT queries. It's assigned as a private instance variable. A class named ActiveRecord_Finder is instantiated by default. This class can be extended for special cases (named after the ActiveRecord extension it belongs to, [ActiveRecordExtension]_Finder). Works fine for me. I see no reason to use static calls.

so, basically we force the user to write a dummy find method.
The QueryBuilder object knows how to build sql select statements based on $args and with the help of an SQLCommand object (somehow inspired by the last year talks on fluid interfaces).

On every informations that we gather, the build method will know how to execute an sql select, how to bind (replace ? with values) prepared statements and how to return instances of the News class with data loaded.

I don't know ruby, so I may be missing a point here, but is a class an object in ruby ? If not, how can you pass the class to a subroutine ?

Sorry for not being clear, but yes, as with everything else in ruby, classes are objects, and can be passed as a method parameter. There's no such thing as a static call in Ruby, all calls are late bound.

Originally Posted by kyberfabrikken

Ah - I get it. You're suggesting to have a separate finder, but to let the activerecord serve as a decorator over it, so that user can decide which approach to use ?
That's a pretty good compromise actually.

A more appropriate term would be a Facade. Fine-grained objects are good for flexibility and maintainability, but can make for overly complex apis, a common problem in class libraries for which the facade pattern is a common solution.

Fewer objects is definitely a concern of mine; domain models can get pretty complicated, and doubling the number of objects by implementing finder classes for each one seems like an inefficient approach to me.

You don't usually need to. Most objects are collection members to other objects. You only need finders for the big top level domain classes and there aren't usually that many.