|
|
|
|
|
by lgunsch
4518 days ago
|
|
I would stick with no classes being "fat". Breaking up fat classes into many smaller classes leads to code being really easy to understand, test, and develop. I tend to stick with the Single-Responsibility-Principle and classes do not become unmanageable. Some people argue that many small classes leads to complex code, but I have not found that to be true in any case I have come across. |
|
I've actually begun building out more "wide" models, that is, models with a great many fields set to allow null/blank, because mixins and abstract base classes are very hard to maintain 3-4 years out. Don't misunderstand me, there's a place for those, but it's easy to get lost on road to abstraction.
Of course, the lesson is that if you're representing complex relationships in code, the implementation is going to wind up complex to some extent.