[rspec-users] Design Pattern proposal for better Rails development

Andrew Premdas apremdas at gmail.com
Wed Nov 5 10:44:41 EST 2008


Thanks David

Just to confirm "up front" was not in any way meant to imply that the design
is fixed or should not be refactored, or even will not need refactoring.
Clarifying my point,
 2)  Use your tests/specs/stories/features combined with your experience
to ensure you design an initial api that is clear and simple and
consequently easier to refactor when the need arises

2008/11/5 David Chelimsky <dchelimsky at gmail.com>

> On Wed, Nov 5, 2008 at 9:12 AM, Andrew Premdas <apremdas at gmail.com> wrote:
> > 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
>
> Be careful with the words "up front" here. To me, they imply that once
> the design is there that you should not expect it to change, which is
> the antithesis of agile. Definitely use your
> tests/specs/stories/features to drive out a simple and clear api, but
> you should also feel absolutely free to improve it at any time.
>
> > 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
>
> Other than my note above about "up front", I generally agree with what
> Andrew says here.
>
> Cheers,
> David
>
> >
> >
> > 2008/11/5 Fernando Perez <lists at ruby-forum.com>
> >>
> >> > 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 at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/rspec-users
> >
> >
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20081105/4ea3f97c/attachment-0001.html>


More information about the rspec-users mailing list