3 ms·

To those who are attacking this article. I think, Steve unfortunately has chosen a somewhat bad example to illustrate a very good point. I have seen countless

by gnufied 15y ago

To those who are attacking this article. I think, Steve unfortunately has chosen a somewhat bad example to illustrate a very good point. I have seen countless examples of complex payment logic shoved down into User model (or CreditCard model), because developer did not had the foresight to see that Payment logic does not belong in User or in CreditCard model. About functional or using higher order functions - yeah go for it. The great thing about Ruby I think is - you can still use best of OO patterns with minimum amount of heavy lifting and sprinkle blocks and lambdas - resulting in pretty neat design overall. Also, functional code != good code sometimes (http://www.drmaciver.com/2008/08/functional-code-not-equal-good-code/ http://www.drmaciver.com/2008/08/functional-code-not-equal-g...)

tptacek 15y ago
Steve isn't talking about which model code belongs to. Nobody is attacking the idea of factoring code out of models. But I'm attacking the idea that the place for any refactored code to go is into its own class.
- gnufied 15y ago
  But I am not talking about which model code belongs to either. I sm saying, the Payment logic probably does not belong in either of the models (User or CreditCard) and should be in its own class and should have an well defined interface - independent of how User is stored or how CreditCard is stored. And I think, thats exactly what steve is talking about.
  - tptacek 15y ago
    I think there may be object bees on you. Just because "logic" doesn't belong in a model class doesn't mean it needs its own class. In Rails, you already have three good places to move code like this to: * The controller class, to generate a populated instance variable used by a view * The helper class, to transform a general-purpose instance variable into the variable you need in your view * As a free function or static method anywhere in lib/, particularly if you could conceivably re-use the code in another project. The issue here is nominalizing all the logic in your code; besides creating unnecessary indirection (indirection is the coin of the realm; spend it wisely), it also creates One More Thing everyone has to remember to use your code: how to instantiate your object. Just write functions. People have built and maintained things far more amazing than blog software in C using nothing but well-named functions. What Would Norvig Do?

by gnufied 15y ago

tptacek 15y ago

Steve isn't talking about which model code belongs to. Nobody is attacking the idea of factoring code out of models. But I'm attacking the idea that the place for any refactored code to go is into its own class.

gnufied 15y ago
But I am not talking about which model code belongs to either. I sm saying, the Payment logic probably does not belong in either of the models (User or CreditCard) and should be in its own class and should have an well defined interface - independent of how User is stored or how CreditCard is stored. And I think, thats exactly what steve is talking about.
- tptacek 15y ago
  I think there may be object bees on you. Just because "logic" doesn't belong in a model class doesn't mean it needs its own class. In Rails, you already have three good places to move code like this to: * The controller class, to generate a populated instance variable used by a view * The helper class, to transform a general-purpose instance variable into the variable you need in your view * As a free function or static method anywhere in lib/, particularly if you could conceivably re-use the code in another project. The issue here is nominalizing all the logic in your code; besides creating unnecessary indirection (indirection is the coin of the realm; spend it wisely), it also creates One More Thing everyone has to remember to use your code: how to instantiate your object. Just write functions. People have built and maintained things far more amazing than blog software in C using nothing but well-named functions. What Would Norvig Do?