3 ms·

fat controllers

by latch 15y ago

fat controllers

jamesbritt 15y ago
Fat anything. Classes should have limited, well-defined behavior, and call out to other objects or use composition when needed.
- jarrettcoggin 15y ago
  Single Responsibility Principle for the win. Definitely comes into play in good design. One of the biggest things I've found is that to constantly look at new ways to approach a problem. Don't just assume you've learned it all. One thing I'd like to learn how to do better is to refactor better.
- philwelch 15y ago
  Absolutely. I think the confusion is between individual model and controller classes and the collective model and controller components of the system as a whole. If you have one fat controller class, that's the worst of all worlds. If you have a plethora of thin controller classes which collectively handle most of the business logic, you still have a "fat controller" in aggregate, even if these controllers have limited, well-defined behavior and call out to each other. What you really want is a thin controller in aggregate, combined with a large but well-separated ecosystem of model classes (which, in aggregate, is going to outweigh the controllers).
  - jamesbritt 15y ago
    If you have a plethora of thin controller classes which collectively handle most of the business logic, you still have a "fat controller" in aggregate, even if these controllers have limited, well-defined behavior and call out to each other. I don't follow this at all. Anyways, what I was getting at was, as jarrettcoggin posted, Single Responsibility Principle. Couldn't think of the name before. A problem I see in Rails code is that some people think you have only three places to put code: M, V, or C. Most people know enough to avoid stuffing code in the view, so they stuff code into either a controller or a model. Not quite "god classes", but demi-god classes at least.
    - philwelch 15y ago
      If you follow the Single Responsibility Principle well enough, you're going to end up with most of your code in model classes most of the time. My point is that it's possible (but still a bad idea) to have tons of tiny controllers, each of them still doing stuff that's better served by a model.

fat controllers

by latch 15y ago

fat controllers

Fat anything. Classes should have limited, well-defined behavior, and call out to other objects or use composition when needed.

jarrettcoggin 15y ago
Single Responsibility Principle for the win. Definitely comes into play in good design. One of the biggest things I've found is that to constantly look at new ways to approach a problem. Don't just assume you've learned it all. One thing I'd like to learn how to do better is to refactor better.
philwelch 15y ago
Absolutely. I think the confusion is between individual model and controller classes and the collective model and controller components of the system as a whole. If you have one fat controller class, that's the worst of all worlds. If you have a plethora of thin controller classes which collectively handle most of the business logic, you still have a "fat controller" in aggregate, even if these controllers have limited, well-defined behavior and call out to each other. What you really want is a thin controller in aggregate, combined with a large but well-separated ecosystem of model classes (which, in aggregate, is going to outweigh the controllers).
- jamesbritt 15y ago
  If you have a plethora of thin controller classes which collectively handle most of the business logic, you still have a "fat controller" in aggregate, even if these controllers have limited, well-defined behavior and call out to each other. I don't follow this at all. Anyways, what I was getting at was, as jarrettcoggin posted, Single Responsibility Principle. Couldn't think of the name before. A problem I see in Rails code is that some people think you have only three places to put code: M, V, or C. Most people know enough to avoid stuffing code in the view, so they stuff code into either a controller or a model. Not quite "god classes", but demi-god classes at least.
  - philwelch 15y ago
    If you follow the Single Responsibility Principle well enough, you're going to end up with most of your code in model classes most of the time. My point is that it's possible (but still a bad idea) to have tons of tiny controllers, each of them still doing stuff that's better served by a model.