您应该有几个类和软件包？

真实世界的经验。

很久以前，那里住着许多编程熊。 每天早晨，哺乳动物熊，爸爸熊和婴儿熊都会在森林深处的僻静小屋中一起吃早餐，然后掏出三台笔记本电脑，花费数小时精心编写Java代码。 有一天，熊们出门购物时，自动化理论和软件工程教授Maria G. Locks迷失在树林里时跌倒在小屋上。 当她透过窗户凝视时，将手捧在玻璃上，窥视着三台笔记本电脑的发光屏幕，并立即砸碎了里面的方式。
她坐在第一台笔记本电脑上，破解了密码，仔细研究了Java源代码。 那真是可怕的一团糟。 只有少数几千个包含数千行功能的可怕类，该结构使她感到震惊。 她心急如焚，搬到第二台笔记本电脑上并破解了密码。 大量的代码大量涌入屏幕，这一次是数百个精巧的程序包承载了数百个微小的类，而每个小类又依次包含了许多相互分离的功能。 她破解了最终密码，在第三台笔记本电脑面前哭泣。

这段代码很漂亮。 这些包装既不能太大也不能太小。 比例匀称的类包含一致的实现细节。 这些功能（经过适当的信息隐藏）可以执行单个任务，而不必大惊小怪。 然后三只熊从前门冲进来，爸爸熊一见到入侵者就怒气冲冲。 洛克斯教授尖叫着跳了起来。 玛咪熊尖叫着喝粥和床，但没人能真正记住这个故事是如何结束的，所以整个事情都被遗弃了。

重点是/h2>

什么时候我们的软件既不会被过度封装，包含太多的包和类，又不会被不足封装，包含太少什么时候才对让我们尝试通过对Java程序建模来回答这些问题。 新手经常问：“你应该上几节课尽管没有意识到他们的遗漏，他们实际上是在问：“我必须满足几个班级以满足特定的约束我们也必须选择我们的约束条件。 现实世界中的约束通常与问题域相关，但是，希望我们的模型尽可能简单地得到广泛应用，因此我们将选择约束作为我们的约束，以使系统可以支持的潜在依赖关系的数量最小化。 也就是说，我们希望最小化系统的潜在耦合 。

尽管很简单，但我们的选择并非没有道理，因为我们希望（深呼吸）将开发软件的成本降至最低，这意味着通过最大限度地减少所涉及的依赖项的数量来最小化涟漪效应更新，并且意味着将鼓励依赖性的条件降到最低。形成，这意味着最大程度地减少潜在依赖性的数量。 毫无疑问，在如此棘手的逻辑链上引起了人们的关注，但该奖项-客观衡量我们应该拥有的功能，类和程序包的数量-可能值得保留。

模型假设。

我们的模型基于两个假设：一个明智，一个完全疯狂。 第一个假设是我们的系统由n个功能组成。 我们的任务是找到应该在上面分配这n个函数的数字类和数据包，以便使潜在的耦合最小化。 第二个假设是，所有函数将均匀地分布在所有类和包中，每个类将具有d函数，对于包中的其他类是可见的，并且每个包将具有相同数量的d ，对于其他类中的其他类可见的函数包。

看到邦克斯。 但并非没有任何理由。 我们知道，几乎在所有情况下，均匀分布的功能都会使潜在的耦合最小化。 因为电位耦合随彼此可见的元素数量的平方增加，所以如果一类具有两倍的功能，则它将具有四倍的电位耦合。

对于每个类都有严格数量的默认访问器功能，以及每个程序包都有公共功能，确切地说，没有人设计这样的系统。 但是，程序员尝试将最大可见元素的数量减到最少，因此我们可以将d = 1作为理想的渐近目标。 当然，一旦系统启动并运行，每个类必须具有平均数量的默认访问器功能，而每个包必须具有平均数量的公共功能。 鉴于我们希望两个数字都较小，因此发现它们可能相似并不奇怪。 但是，我们的假设是这样。 自己判断它们的合理性。 最后，让我们为我们的采石场贴上标签：我们希望知道我们的系统应该有多少个包装p _a和类r 。 因此，我们如何找到p _a和r

函数看到了什么。

让我们在假设的，分布均匀的系统中采用任何函数-我们将其称为 ，然后问： 还可以看到多少个其他函数这里的一切都源于这个问题。 可以看到三组函数。 它可以在自己的类中看到函数。 它可以在自己的包中查看其他类中的函数。 它可以看到其他包中其他类中的函数。 这三组合起来构成了可见的所有功能，也就是说，它们提供了的潜在耦合。 出于显而易见的原因，我们希望找到这种潜在耦合的方程式。 为此，我们必须找到三个术语，每个术语对应于这三个组。

自己班上的职能。

图1：自己类中来自test1（）的潜在依赖关系。

图1显示了三个包，每个包具有两个类，每个包具有三个功能。 红色函数是公共的（它们的类也是公共的），绿色私有和默认访问器的函数是蓝色的。 我们的函数被随机选择为左下角的函数，如全文所示。 在自己的类中可以看到多少个函数好吧，它可以看到所有人。 在上面的示例中，它可以在其类中看到其他两个函数。 我们知道任何类中的函数数就是函数的总数n除以类的总数r ，因此我们可能会认为该数是n / r 。 但这还包括对自身的依赖关系，而我们要忽略它，因此可以形成的依赖关系的数量比类中函数的数量少一个，即：

自身包装中的功能。

图2：自己程序包中来自test1（）的潜在依赖关系。

在自己的包中的其他类中， 看到多少个函数它可以看到那些不是包中所有其他类都私有的函数。 在上面的示例中，它只能看到另一个公共功能。 我们知道，这是不是私人的每一类功能的数量被定义d。 而且我们知道每个包的类数只是类的总数r除以包数p _a ，尽管如此，我们还是希望排除对其依赖形成依赖的可能性自己的课。 因此，它在自己的程序包中可以看到的功能数为：

其他软件包中的功能。

图3：从test1（）到其他程序包的潜在依赖关系。

在其他软件包中， 看到多少个函数它可以在所有其他包中的所有公共类中查看所有公共功能； 上面的示例显示了它对其他两个公共功能的依赖性。 我们知道，根据定义，包的数量为p _a ，每个包的公共功能的数量为d 。 同样，我们将打折在其自己的程序包中形成依赖关系，因此它在其他程序包中可以看到的功能数为：

这是构成我们功能的潜在耦合的三个术语。 要找到整个系统的潜在耦合，我们只需将它们乘以函数总数n ，即可得出关于潜在耦合s的最终方程：

现在，众所周知，学习Java的学生最大的抱怨是偏微分方程太少了。 碰巧，我们寻找类和包的数量以最大程度地减少潜在耦合的尝试正涉及这样的野兽：因为我们面临优化问题。 还记得那些高中生吗将导数设置为零并求解这就是我们现在要做的，谢谢牛顿先生……呃，莱布尼兹先生……等等。 为了找到最小化潜在耦合s的类r ，我们计算s相对于r的导数：

为了找到最小化潜在耦合s的包装数量p _a ，我们计算相对于_a的s的导数：

求解两个联立方程可得出以下解决方案：

因此，如果您有一个包含400个函数的系统，即n = 400 ，并且目标是使一个包中每个类可见5个函数，即d = 5 ，那么您应该拥有的包数是4，每个包具有18个类。 图4绘制了模型在x轴上所有可能数量的程序包和y轴上所有类的数量的400个函数的潜在耦合关系，每个坐标上的红色均与由生成的潜在耦合量成比例包裹和类别编 的组合； 因此，浅粉红色意味着极低的电位耦合。 （该图是三角形的，因为我们不能少于非空包。）黑色正方形表示潜在的耦合最小值。

图4：400个功能的潜在耦合与封装和类编 的关系，其中d = 5。

当然，您永远不会创建这样的系统。 只有4个软件包来处理如此多的功能，打击得太少了。 残酷的现实肯定会干扰并规定8个软件包或10个软件包。这就是系统效率^*发挥作用的地方。 效率为100％的系统与效率为100％的蒸汽机一样罕见。 您应该高兴地下降到80％或70％的效率，以为设计赢得更多的空间，比限制性的理想情况所需的更多地享受语义驱动的程序包和较少规则的分发。 但是，您可能会犹豫不决，只接受效率仅为40％或30％的封装，从而使您的系统面临大量依赖关系以及随之而来的连锁效应成本的可能性。 红外护目镜时间。 图5显示了我们400个函数的效率热图，这些函数是由上面导出的相同电势耦合方程生成的。 深蓝色区域显示出超过90％的效率，这是一个人脚未曾踩踏过的热带岛屿。 青色，绿色和黄色带提供了在实用性和潜在费用之间进行更合理权衡的配置。 红色区域，很好……

图5：400的绝对理想效率是包装和等级编 的函数，d = 5。

摘要

您应该有几个类和软件包现在，“取决于。” 这尤其取决于您选择要满足的约束。 这里选择的约束条件是试图通过最小化潜在的纹波效应更新来最小化开发成本。 一个简单的模型是基于一些可疑的假设而得出的，这些结论可能会得出一些有趣的结论，但可以以复杂性为代价轻松扩展该模型，以更准确地捕获现实，但是最终，该模型本身提供的东西可能更少而不是它的构思方法。 无论您决定拥有多少类和程序包，至少要了解做出决定的原则。 唯一不好的设计是没有设计。

笔记：

*为了获得绝对理想的效率，

参考： 您应该有几个类和软件包 从我们的JCG合作伙伴 Edmund Kirwan在有关软件的A博客上获得。 博客。

翻译自: https://www.javacodegeeks.com/2013/04/how-many-classes-and-packages-should-you-have.html

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树类和接口类和面向对象92005 人正在系统学习中 相关资源：台湾版平彼电脑测试软件_比鲁大师好的测试电脑软件-硬件开发其他…