3 ms·
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 CreditCa
by 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 agoI 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?