Ok, time to embarrass myself due to lack of Ruby/programming knowledge. A few questions that perhaps someone can clear up as from my OO perspective this, to me, is all over the place. I must admit I'm only just getting started on Ruby.
Firstly, that doesn't look like the strategy pattern to me, isn't it back to front? And even if it were, what the hell are you doing? You do not pass the user to the authenticator, you'd pass the authenticator to the user constructor.
The way you've chosen is very brittle, it's a sure fire way to accidentally shoot yourself in the foot later on when someone accidentally deletes the authenticator or adds a new code path that doesn't contain one.
I also don't understand why you're creating a new class per object query? Ditto for the policy stuff. Why not just use a repository object if you don't want to clutter your main class. Like OrderRepository.GetByCompany(Id).
As for point 7, I don't understand why you're not completely extracting the facebook integration from the comment class. Does Ruby not have events? Why aren't you firing an event that the facebook integrator that initialized on the user object subscribed to? i.e. make a facebook integrator that registers itself on the user object creation.
Also, "View Model" not "View Object", that's what they're called, a lot of other frameworks already use them.
Good points/questions. I'll try to respond to each...
* RE: Strategy pattern. My understanding of the strategy pattern is it simply refers to "algorithms are encapsulate and can be selected at runtime". (http://en.wikipedia.org/wiki/Strategy_pattern)
* RE: New class per object query. Agreed that grouping these can make sense. Had to keep the example brief.
* RE: Events. That's another approach -- thanks for the suggestion.
* RE: "View Model" vs. "View". I had it as "View Model" in the original draft and got feedback from reviewers that they are usually called just "Views". :-) I've heard it both ways .
Firstly, that doesn't look like the strategy pattern to me, isn't it back to front? And even if it were, what the hell are you doing? You do not pass the user to the authenticator, you'd pass the authenticator to the user constructor.
The way you've chosen is very brittle, it's a sure fire way to accidentally shoot yourself in the foot later on when someone accidentally deletes the authenticator or adds a new code path that doesn't contain one.
I also don't understand why you're creating a new class per object query? Ditto for the policy stuff. Why not just use a repository object if you don't want to clutter your main class. Like OrderRepository.GetByCompany(Id).
As for point 7, I don't understand why you're not completely extracting the facebook integration from the comment class. Does Ruby not have events? Why aren't you firing an event that the facebook integrator that initialized on the user object subscribed to? i.e. make a facebook integrator that registers itself on the user object creation.
Also, "View Model" not "View Object", that's what they're called, a lot of other frameworks already use them.