What you are suggesting here changing your api to make it easier to refactor your api. Your trying to do this by
1) Generalising the descriptivness of the api 2) Reducing the number of calls to your api Both of these are not particularly good ideas 1) Generalising your api, reduces it descriptivness and in sample you give actually makes you api non descriptive. Instead of methods find_if_purchased, you now have methods like find_for_index. What you've done here is pollute the api for your model with stuff outside its concern (namely the controller) 2) You actually want to increase the number of calls to your api. The more it is called the more useful it is being, and the more thoroughly it is being tested. If you have no calls, you would not even need to implement it. As for solving the problem of refactoring api's quickly there are two solutions to this 1) Use your editors search and replace functionality 2) Use your tests/specs/stories/features combined with your experience to ensure you design a simple and clear api up front Finally your examples were of a poor api, being refactored into a poorer api. By increasing the number of parameters of your interface. you have increased by a factor of 4 the number of possible parameter combinations you have to deal with. Refactoring your unit test for this method should make that ubundantly clear, and encourage you to change your api. In fact in this case the method is in completely the wrong place what you should have is product.purchased? product.purchased_by_user?(user) Hope this helps All best Andrew 2008/11/5 Fernando Perez <[EMAIL PROTECTED]> > > Hmmm, could you make a helper module and mix that into all three > > controllers? Then there'd be just one place to change it. > > > Can you be more descriptive? > > Let's say I have: > > def show > Subscription.find_if_purchased > ... > end > > def update > Subscription.find_if_purchased > ... > end > > > Now if I change the method name to find_if_subscribed in the model, then > necessarily I will have to change it twice in my controller, well I > could use a before_filter, but what if the method is also called in > other controllers? That's the main problem. How would you do that? > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
