When you are developing, when can you determine if you have a lot of unnecessary classes in your application? Is there a certain limit on how many classes you should have?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
When you are developing, when can you determine if you have a lot of unnecessary classes in your application? Is there a certain limit on how many classes you should have?
There really isn’t such a thing as “too many classes.” What can be a problem is “too many classes doing the same thing.”
If you feel that you have too many classes in your codebase, a good way to audit that would be to add some new requirements. Anything that forces you to make some changes to the code. (In a separate branch of the source control, of course.) How difficult is it to make those changes? Does a relatively simple change require that you modify tons and tons of classes? If that’s the case then there’s a very good chance that you do have too many, but the problem isn’t the number itself.
It’s primarily a matter of personal preference in many cases. There’s often a trade-off between code re-use and code de-coupling. By separating out every concern possible and having lots of small classes, you de-couple everything from everything else. However, you often find that you have to repeat code in such cases because a lot of code might be doing “the same thing” but for a slightly different reason.
On the other hand, if you insist on never repeating anything in the code, then while you get fewer classes you also often end up with more coupling because a single class will have multiple responsibilities to any code which requires similar functionality.
The bottom line in most cases is resistance to change. Coupling vs. re-use is something people can argue about at length, but software rigidity is where the argument turns into actual effort (money). Test how difficult it is to make changes to the code. Then try re-arranging your classes/logic in a manner that you think would be more accepting of change and test it again. Was there a significant improvement?