道金斯在神的物体上

遇见敌人。

冒着热气的丛林压碎了您的周围，昆虫在空中蔓延，奇怪的咕unt声在树叶上颤抖，您深深地停留在未知的重构中，远离喘息，远离家乡，无助。 汗水从所有毛Kong渗出。 您的砍刀因一万次砍伐而开凿和钝化，疲惫地挂在call的抓地力中，而您的思想却变得无精打采。 在您的身后，没有任何记录下来的记录：无数的葡萄藤被割断，无数的依赖被撕毁，无数的破烂阶级搁置一边，这些都没有改变缠结的疯狂。 您的所有烦恼的重组似乎都是浪费，毫无意义，这是因为粗野的野蛮人爬上树丛而行。

然后，您会看到黑暗。 迷路了，走近时并没有注意到它，它形成了广阔而微妙的阴影。 恐惧充斥着你的灵魂。 您交错地穿过树林，被恐怖吸引，每一步的灯光都开始失效。 轻率的砍伐不能使野猪远离肉体，但会继续前进。 你一定要看 您必须看到它。 最后一堵粘稠的植被墙会绊倒你。 远景在您面前打开。 怪物展现自己。

上帝反对。 巨大的野兽从森林地面蔓延到树冠，令人窒息，使天空窒息。 卷须到处都是蛇，从*的密集处散发出来，窒息了他们接触的每个阶层。 更糟糕的是，肥大的结实的依赖性从四面八方撞向神的物体的巨大核心，这是扭曲，盘绕和刺穿的疯狂。

打败了，你崩溃了到膝盖，弯刀从你的手中溢出。 绝望一跳。 你低下头。 在那里，在您面前的地面上，有些东西闪闪发光，有些东西银色，并且位置不正确。 利用您的最后力量，您可以伸出手来捡起金属标签。 微弱的写作打分表面。 它显示为“ MavenProject.java”。

规模和目击事件。

术语“上帝的对象”是许多对象。 所讨论的动物根本不是物体，而是一类动物，不是电驱动编排器通过高速总线对数据进行ping操作的编排，而是一个文本文件，尽管它是一个适度的动物。 许多人也不太同意尊敬的Wikipedia的说法，即我们的采石场需要具有以下功能：……程序的大部分整体功能…编码为单个“全知”的对象，该对象保留了有关整个程序的大部分信息并提供了大多数处理这些数据的方法。” 考虑到当今的企业庞然大物，例如，一个拥有银行系统中更好部分的单一阶层将是一个奇妙的事情。 取而代之的是，大多数人会认为上帝对象是干得太多，职责太多或代码行太多的任何类。 这就引出了一个问题：什么太多了？ 很少有人会考虑一类两百行的文字。 当然，可能是：存在异常值和稀有异常，但是仅凭其规模，合理的200行类别几乎不会引起怀疑。

一类五百行的电话可能会遇到一些开玩笑，严厉的审问。 但是，如果有经验的设计师证明其合理性，它也可以通过审核。 这些事情总是有原因的。 然而，在一千行长的情况下，一门课已经跨越了潜规则。 好味道被冷落了，侮辱了良种。 有人在品尝葡萄酒时掏出一罐啤酒。 一千行似乎太分手了。 这个班级真的集中了一个单一但又巨大的责任，以至于不能将其一分为二吗？ 真？ 当一千五百列警车从出租车上驶向审稿人的红地毯时，“最讨厌的评论”无疑是“最愚蠢的评论”。 狗仔队给相机拍照，但难以置信而不是钦佩却促使他们旋转百叶窗。

两千行-也许只是-表示提升敬虔。 它可能无法容纳该程序的大多数功能，但是亲爱的，哦，亲爱的班级足够聪明，可以在挥舞刀片式审阅者之后逃脱审阅者，并且如此之大，几乎值得一两个神rine树立。 这样的类可以证明其自身的不可分解性是合理的，即使是最易受骗的软件架构师也无法相信。

此外，上帝的对象分为两类。 第一个是自治的神物，尽管它在所有良好的结构原理上都尖叫着痴呆的虐待行为，但至少它自己有这样做的风度，被隔离在某个角落。 很少有类依赖于这种上帝对象。 一两个其他类必须使它生效，之后它会为做大量的事情而大张旗鼓，但是至少将其拆分成较小的类不会准确地遍历整个系统，因为很少有其他类依赖它。 它的相对孤立性使这种类型的上帝对象成为两种邪恶中较小的一种。 第二类公共神对象拥有大量的依赖类。 这种类型可以直接依赖于它的二十，三十甚至四十个其他类，当程序员尝试分解时，所有这些类都遮住眼睛并通过咬紧的牙齿吸气。 在接近这些神物的地板时，聆听嘎吱嘎吱的嘎吱作响的声音，这些碎片散落在破碎的职业中。 你见过一个吗？ 您见过公共神的物件吗？ 如果没有，请坐下来，发现一些难以忍受的东西……

看哪，戈贡！

图1：MavenProject神对象。

没有图像可以保证野兽的存在。 结构图只能引起不回答问题。 粗略地浏览 MavenProject类本身会发现完整的2200行代码，是某些人认为MavenProject大小的四倍，实际上是一个独立的程序包。 问题是：当面对这样的挫伤时，您应该怎么办？ 程序员通常做以下三件事之一。 首先，他们可能只是换个角度看，是一个通用的解决方案。 其次，他们可能会开始将它们可以使用的方法分解为较小的类。 两种选择都有其优点。

但是，第三个选择经常被忽略。 此选项承认神物的动力。 他们之所以如此之大，是因为他们这样做：他们得以成长。 他们很少停滞不前，通常不会仅仅因为您决定介入并取得控制权而停止使用功能。

在持续增长的假设下，第二种选择似乎摇摇欲坠：就像九头蛇一样，上帝对象注视着您砍下的课程，他们很快就会开始挣扎，吞噬和成长。 内聚性降低，并且所有这些依赖性直接串入新的实现类中，耦合成为问题。 第三个选项建议您不要完全减小上帝对象的大小。 至少在最初。 取而代之的是，您仅开始创建由God对象实现的小型接口，并且以前上帝对象的客户端将注意力转移到这些接口上。 关于这些小型接口的性质存在意见分歧。

一个阵营建议分析上帝对象的功能，并在语义上对它们进行分组。 这具有保持新接口不相交，不共享公共功能声明的优点，但是具有使客户端接收其可能不会使用的所有功能的接口的缺点。 另一个阵营建议为每个客户端程序包（或重要类）创建一个新接口，使这些接口比特定于提供程序的客户端更具客户端性。 这样做的好处是，客户端可以完全准确地使用它们接收的接口，但缺点是许多接口可能声明相同的功能。

实际上，有些方法从第二种方法开始，并在完成后将重复的函数声明收集到公共的扩展接口中。 无论取得什么成就，这只是第一步。 一旦倒数第二个对神物体的依赖性突然消失，刀子仍应保持护套。 必须首先将野兽设为程序包专用（Java的默认访问修饰符），以便将来的客户端无法绕过接口，然后最好将其移至其自己的新程序包中，而将接口留在后面。 只有这样，当神的对象与所有其他对象隔离开来，并且界面现在以立面的形式展现出来时，解剖才能开始。 听起来可能需要做很多工作。 它是。 没有人说这会很容易。

但是，最终的配置提供了到客户端的接口外观，这些客户端不受解耦的实现重构的困扰，并提供了一个单独的程序包，从程序中发出的尖叫声在整个程序中散发出来。 一阵子。 只是为了好玩，我们可以对MavenProject类进行X射线检查以查看其胆量。 大型类通常会建议它们自己的提取，并且如图2所示， deepCopy()函数看起来很诱人。

图2：MavenProject的功能。

摘要。

上帝反对：不要。

照片信用归因。

• CC Image Jungle和《太阳报》由Flickr上的yassina提供。
• CC Image 珀尔修斯（Perseus）在Flickr上的莫尼托西（Monitotxi）赢得美杜莎（Medusa）的胜利 。

翻译自: https://www.javacodegeeks.com/2013/04/going-dawkins-on-god-objects.html