问题描述
在开发时，何时可以确定应用程序中是否有很多不必要的类?您应该有多少门课有一定的限制?
确实没有太多的类"这样的东西. 可能会出现的问题是有太多类在做同样的事情."
如果您认为代码库中的类太多，则审核的一种好方法是添加一些新要求.任何迫使您对代码进行更改的内容. (当然，在源代码管理的单独分支中.)进行这些更改有多困难?相对简单的更改是否需要您修改大量的类?如果是这样，那么您确实有太多机会，但是问题不在于数字本身.
在许多情况下，这主要是个人喜好问题.在代码重用和代码去耦之间通常需要权衡取舍.通过分离出所有可能的问题并拥有许多小类，您可以将一切与其他一切分离.但是，您经常发现在这种情况下您必须重复执行代码，因为很多代码可能在做同一件事"，但原因稍有不同.
另一方面，如果您坚持不重复任何代码，那么在获得更少的类时，您通常也最终会产生更多的耦合，因为单个类将对需要类似功能的任何代码承担多种责任. /p>
在大多数情况下，最重要的是改变的抵抗力.人们可以争论耦合与重用，但是软件的刚性是争论变成实际努力(金钱)的地方.测试更改代码有多困难.然后尝试以您认为会更接受更改的方式重新安排您的类/逻辑，然后再次进行测试.有明显的改善吗?
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?
这篇关于有太多的课吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！