有几个软件包无法下载_您应该有几个类和软件包？

有几个软件包无法下载

真实世界的经验。

从前，那里住着一头编程熊。 每天早晨，哺乳动物熊，爸爸熊和婴儿熊都会在森林深处的僻静小屋中一起吃早餐，然后掏出三台笔记本电脑，花费数小时精心编写Java代码。 有一天，熊们出门购物时，自动化理论和软件工程教授Maria G. Locks迷失在树林里时跌倒在小屋上。 当她透过窗户凝视时，将手捧在玻璃上，窥视着三台笔记本电脑的发光屏幕，并立即砸碎了内部。

她坐在第一台笔记本电脑上，破解了密码，仔细研究了Java源代码。 那真是可怕的一团糟。 只有少数几千个包含数千行功能的可怕类，该结构使她感到震惊。 她心急如焚，搬到第二台笔记本电脑上并破解了密码。 大量的代码大量涌入屏幕，这一次是数百个精巧的程序包承载着数百个微小的类，每个包又反过来阻止了许多相互分离的功能。 她破解了最终密码，在第三台笔记本电脑面前哭泣。

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

重点是什么？

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

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

模型假设。

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

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

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

函数看到什么。

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

自己班上的职能。

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

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

自身包装中的功能。

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

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

其他软件包中的功能。

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

在其他软件包中， 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。

摘要

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

笔记：

*为了获得绝对理想的效率， 并且当d = 1

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

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

有几个软件包无法下载