From an OOP standpoint, if a type becomes unmanageably large, it can often be divided up into separate types as it probably contains code that has nothing to do anymore with the actual purpose of the class.
When creating a class, decide carefully what exactly it's purpose is and make sure that the code in it serves only that purpose.
I know it is convenient to 'just add this and that' at times but it runs the risk of creating a class that is ambiguous in it's use.
Ofcourse it is always possible to stick to these rules and still get a class that is just so damn huge it becomes hard to maintain, but tbh in my 6 years of OOP programming I have never had that happen to me.
I did create some large classes, but careful consideration showed that I had broken those rules and the class could easily be made more manageable by taking out unrelated parts and giving them their own classes.
Classes that become too complex to handle are more often the result of design mistakes on the developers side, then they are out of necessity.
When creating a class, decide carefully what exactly it's purpose is and make sure that the code in it serves only that purpose.
I know it is convenient to 'just add this and that' at times but it runs the risk of creating a class that is ambiguous in it's use.
Ofcourse it is always possible to stick to these rules and still get a class that is just so damn huge it becomes hard to maintain, but tbh in my 6 years of OOP programming I have never had that happen to me.
I did create some large classes, but careful consideration showed that I had broken those rules and the class could easily be made more manageable by taking out unrelated parts and giving them their own classes.
Classes that become too complex to handle are more often the result of design mistakes on the developers side, then they are out of necessity.