如何证明或反对“上帝的物体”是错误的？

问题摘要：

长话短说，我继承了代码库和不允许更换的开发团队，使用God Objects是一个大问题。展望未来，我想让我们重构事情，但是我从那些想与God Objects一起做所有事情的团队中得到了回击，“因为它更容易”，这意味着我将无法重构。我以多年的开发经验为后盾，我是受雇来了解这些事情的新老板，等等，第三方离岸公司的销售代表也是如此，现在这是在执行层和我的会议上现在是明天，我想投入大量技术弹药以倡导最佳实践，因为从长远来看，我认为这对于公司而言会便宜得多（而且我个人认为这是第三方所担心的）。

我的问题是从技术角度讲的，我知道它的长期稳定性，但是我在超短期和6个月期限方面遇到了麻烦，尽管我“知道”我无法通过引用和引用的资源来证明这一点。一个人（罗伯特·C·马丁，又名鲍勃叔叔），因为我被告知要从一个人那里获得数据，而只有一个人（罗伯特·C·马丁）的论点不够好。

题：

我可以直接引用一些本领域知名专家的资源（标题，出版年份，页码，报价），这些资源明确表示对“上帝”对象/类/系统的这种使用不好（或很好，因为我们正在寻找）技术上最有效的解决方案）？

我已经做过的研究：

1. 我在这里有很多书，并且已经搜索了它们的索引以查找单词“ god object”和“ god class”的使用。我发现奇怪的是它几乎从未使用过，例如我所拥有的GoF书的副本就从未使用过（至少根据我面前的索引），但是我在下面的两本书中找到了它，但是我想要更多我可以用。
2. 我在Wikipedia页面上检查了“上帝对象”，并且该页面当前是一个存有很少参考链接的存根，因此尽管我个人同意它说，但在个人经历被认为无效的环境中，我没有太多用处。被引用的书也被认为太老了，无法被我在讨论这些技术要点的人们接受，因为他们提出的论据是：“曾经被认为是不好的，但没人能证明它，而现在的现代软件则说：”上帝“对象很好用”。我个人认为这句话是不正确的，但无论事实如何，我都想证明事实。
3. 在罗伯特·C·马丁（Robert C Martin）的“ C＃中的敏捷原理，模式和实践”（ISBN：0-13-185725-8，精装本）的第266页中，它指出：“每个人都知道，神的阶级是个坏主意。我们不想将系统的所有智能集中到单个对象或单个功能中。OOD的目标之一是将行为划分和分布到许多类和许多功能中。” -然后继续说有时还是最好还是使用上帝课程（以引用微控制器为例）。
4. 在罗伯特·C·马丁（Robert C Martin）的“清洁代码：敏捷软件技巧手册”第136页（仅此页面）中，谈到了“上帝的阶级”，并称其为违反“阶级应该很小”规则的主要例证。从第138页开始，他使用了“单一责任原则”。

我遇到的问题是，我所有的参考文献和引用都来自同一个人（Robert C. Martin），并且来自同一个人/来源。有人告诉我，因为他只是一个观点，所以我不使用“上帝类”的愿望是无效的，并且未被接受为软件行业的标准最佳实践。这是真的？从技术的角度来看，我是在努力遵循鲍勃叔叔的教导做错事情吗？

上帝对象和面向对象的编程与设计：

我对这一点的思考越多，我就越会在学习OOP时学到更多，而且从来没有明确指出过。它对良好设计的暗含是我的想法（请随意纠正我，因为我想学习），问题是我“知道”这一点，但不是每个人都知道，因此在这种情况下，它不被视为有效的论证，因为当实际上大多数人在统计上都不了解它时，我实际上将其称为普遍真理，因为从统计学上讲大多数人都不是程序员。

结论：

我不知所措，想获得最好的附加结果来引用，因为他们提出了技术要求，并且我想知道真相并能够像真正的工程师/科学家一样被引用证明事实，即使由于我对使用神物的经验，我对神物有偏见。任何帮助或引用将不胜感激。

通过确定现有设计产生的痛点来做出任何改变做法的理由。具体来说，您需要确定哪些因素比现有的设计要困难，哪些因素易碎，什么正在破坏，哪些行为无法通过简单的方式直接实现（甚至在某种程度上是间接的）结果？当前的实施情况，或者在某些情况下会影响性能，使新的团队成员迅速掌握需要多少时间，等等。

其次，工作代码胜过任何有关理论或良好设计的争论。不幸的是，即使对于错误的代码，也是如此。因此，您将不得不提供更好的替代方案，这意味着您作为更好的模式和实践的倡导者，将需要重构以梳理出更好的设计。在现有设计中找到一个狭窄的，示踪子弹式的平面，并实现一个解决方案，该解决方案可能在迭代过程中保持上帝对象的实现正常工作，但将实际实现推迟到新设计。然后编写一些利用这种新设计的代码，并展示由于这种变化而赢得的收益，无论是性能，可维护性，功能，错误或竞赛条件的纠正，还是开发人员的认知负担的减少。

找到足够小的表面积以在架构欠佳的系统中进行攻击通常是一个挑战，它可能比您想要提供一些初始值所需的时间更长，并且初始收益可能不会给每个人都那么令人印象深刻，但是您也可以工作如果您与至少有点同情的团队成员配对，就可以找到一些新方法的拥护者。

哀叹上帝的对象只有在您向合唱团宣讲时才有效。这是一个命名问题的工具，并且只有在您的接收者年纪大，有足够的动力去解决问题时，才可以解决问题。修复上帝的对象会赢得争论。

由于您的直接关注似乎是高管人员的支持，所以我认为最好将替换此代码作为战略目标并将其与您负责的业务目标联系起来。我认为您可以提出一个可以提供一些技术指导的方法，方法是首先研究一个技术峰值，以解决替换问题，最好是由一个或两个对当前设计有所保留的技术人员提供资源。

我认为您已经找到了足够的资源来论证您的论点。参加此类会议的人们只会关注您的研究摘要，在您提到两个或三个佐证的消息来源后，他们将停止收听。最初，您的重点应该放在购买股票上，以解决您看到的问题，而不必证明别人做错了或您自己是对的。这是一个社会问题，而不是合乎逻辑的问题。

在技​​术领导角色中，您需要将您的任何计划与业务目标联系在一起，因此，向高管提出申诉的最重要的事情是针对这些目标的工作。因为您也被认为是“新人”，所以您不能仅仅期望人们放弃他们的工作或期望很快就落伍。您需要通过证明自己可以兑现来建立信任。从长远来看，在领导角色中，您还需要学习专注于结果，但不一定要着眼于结果的细节。您现在在这里提供战略指导，消除团队进步中的战术障碍，并提供团队指导，而不是与自己的团队成员赢得信誉之战。

除非您在游戏中有皮肤，否则做出自上而下的决定几乎是不可信的。如果您再次处于类似的情况，则应将更多精力放在组织内部建立共识上，而不是一旦感觉情况失去控制就升级。

但是考虑到您现在的位置，我想说的最好是争辩说，您的方法将根据您的经验带来可衡量的长期利益，并且与Bob和叔叔等公司的知名从业者的工作相吻合。 ，而您想以身作则，花上几天/几周的时间来进行最高性价比的狭窄重构，以展示您对良好设计的看法。但是，您需要根据个人喜好将具体情况与特定的业务目标保持一致。

首先，您需要提出任何可衡量的组织都必须采用行业最佳实践。说“它对我们有用！” 时间和资源都无法衡量，因为它根本无法预测。与其他任何科学领域一样，软件工程也是一门科学，并且已经对这些概念进行了研究，研究，测试和记录。

1. 在神的对象是一个反模式，其指出，

   在软件工程中，反模式（或反模式）是在社交或业务运营或软件工程中使用的模式，通常可以使用但在实践中无效和/或适得其反。

2. 在2009年的Google IO会议上，在解释MVP模式时部分解释了该主题。它可能与上帝物体无关，但可能会给您一些弹药。

3. 同样，使用此反模式违反了面向对象设计中的单一责任原则，该原则指出：

   每个班级应负一个单一的责任，而该责任应完全由班级封装。它的所有服务都应严格地与这一责任保持一致。

4. 该衰变代码博客中还谈到了这一点，它的解决方案。

5. 我们不能不谈论对象耦合而谈论单一责任原则。

   耦合或依赖性是每个程序模块依赖于其他模块中每个模块的程度。

   如果系统紧密耦合可能会导致assembly of modules [to] require more effort and/or time [to maintain] due to the increased inter-module dependency.较高级别的对象耦合，则凝聚力会降低，反之亦然。上帝对象是紧密耦合的一个很好的例子，因为它们比应有的知识要多，从而使它们负担过多，从而极大地限制了代码的可重用性。

6. 在设计复杂的应用程序时，必须想到简单性。大问题必须分解成较小的问题，以便于管理，测试和记录。在面向对象的范例中尤其如此。

   有了这个论点，我们确实回到了反模式论点，但是这个范式全是关于模式，真实世界对象表示以及最终的数据封装。

7. 当您说这些“良好做法”在教室中更存在时，您说的没错。但是，我确实在大学（和某些大学）中有教学经验，并且我只看到这些原理在大学中，尤其是在工程系中教授。真伤心 但是，像任何良好实践一样，那些努力改善自己的人通常会学习一些基本的设计模式，并最终了解如何在耦合和内聚之间进行探索。

   我平时教给学生的是，它可能似乎需要更多的努力，通过良好的编程标准，但它始终从长远来看还清。一个很好的例子是有人要求程序员编写排序功能。程序员有两种选择：1）编写一个快速的气泡排序函数（少于5分钟），该函数随着元素列表的增长而变得不可持续，或者2）编写一个更复杂（也称为优化）的排序算法（快速排序等），它将更好地扩展具有更大的列表。

哦，我走了，解决了另一个老问题，但是我猜你没有赢得这场辩论，这就是原因。

听起来像是文化问题

您是他们的经理，但您不能取代他们，而您必须去找您的经理，以便让他们去做您认为他们应该做的事情，在这种情况下，我认为这至少是要与上帝决裂对象向前移动。在我看来，这就像是代码的典型案例，它反映了其原始文化。换句话说，上帝的对象是该公司的运作方式。想要做出任何有意义的改变？最终，您总是要去同一个地方，因为所有决定显然都必须在顶部清除。

曾经经历过多次尝试遗留代码清理和代码策略更改的失败尝试，现在我认为，当这种文化仍然牢牢根深蒂固时，或者至少至少在这种文化中，您无法与那种使代码成为可能的文化相抗衡文化是一个非常艰难的艰难时期，任何人都不可能向我支付足够的薪水或给予我足够的力量，以致觉得这是一次很有价值的尝试，有可能再次成功。

在进行更改之前，必须激励他们进行更改，但是不幸的是，作为程序员，他们偶尔会花很多时间阅读Stack，这使我们很难理解，并不是每个人都受同一东西的激励。在我的经历中，我赢得了许多理性的争论，但最终，该公司由于某种原因而遭受了智力上懒惰的开发人员的折磨。

也许是出于商业上的考虑才开始考虑明天，而不是下周或五年。（当您是一个来自北极的国家的移民的孩子时，情况尤其令人沮丧，因为在启示录中，该国家在北极建立了种子库）。也许他们害怕改变。也许他们过于珍惜资历，以至于指挥链毫无意义，即使他们不得不从外部雇用来聘请开发团队负责人或经理，因为他们认识到整个生命周期中没有人成长足够在那里（或者因为所说的生命者不想承担责任带来的风险）。或者，我已经看到了这一点，也许这是平庸的自我拥护的一种非常现实而令人沮丧的现象，因为它深深地知道它可以做到。

您如何应对最终根源于恐惧或成功指标失败的问题？我会告诉你的是，这甚至比一支敬业的质量开发团队要多得多，而发布Q时的声音要少得多。

在不是不可能的文化问题的不可能事件中...

现在假设高层管理人员非常乐于接受变化，并且他们实际上愿意相信您能够做到这一点，那么您实际上只需要用金钱和失去的机会来打断所有争论。

每当在此荒谬的代码库上训练新手所需的时间更长，每次在某事物上修改或添加新功能所需的时间更长，每次要与您合作的公司将端点公开到另一个系统上变得极为困难时， ，这很花钱。很多骗人的钱。最重要的是，它为较小的敏捷竞争对手打开了一扇窗户，让您进入一个位置，您所能做的就是对他们的反应太慢，最终将其全部夺走。

只需认识到，即使公司的实际实体屋顶实际上因此而着火，一种特别顽固和愚蠢的文化仍将不惜一切代价维持现状。

您可以引用一些最基本的OOP原则，例如松散耦合和高内聚性。“神的对象”听起来像是耦合了不相关的类，并且内聚性很低。

你总是可以问鲍勃叔叔本人。

事实是，无论从任何意义上来说，它对人们来说都是如此明显，以至于一旦阐明了这一点，就无需被众多作者重新引用。只需一个来源。

在查找来源时，您可能要开始使用的其他术语是：

• 固体
• 得墨meter耳定律
• 大泥球

所有这些表达了相关的概念，尽管实际上并没有这样命名，但它们可能会产生可行的参考源。

最终，您是老板。这样做的原因是因为您这样说，尽管您被认为是一位好的经理，但您确实应该准备证明自己的决定合理；您已经做到了，并且如果仍然存在阻力，那么正确的行动方法就是让您的团队按照他们的指示去做。

如何证明或反对“神”对象是错误的？

你不能。

这种猜想不适合数学证明，而数学证明是唯一有道理的证明。

即使您尝试用可量化的衡量使用神物的效果来代替情感单词“ wrong”，您也会发现：

1. 可用的措施是粗略的
2. 很少有可靠的研究对那些由专业程序员产生的代码进行量化的措施
3. 几乎没有任何可靠的研究将语言构造或设计（反）模式与这些措施相关联。

而这忽略了确定特定对象何时是“神”对象的问题。

这些研究充其量只能证明经验上的相关性。不是真正的证据。

您实际上正在做的事情是辩论 “神”对象的利弊，以期改变他人的观点 ……然后改变您组织的实践。

不要使用诸如“证明”之类的词，否则与您辩论的人可能会笑着面对您。

您可能想看看本周的大师＃84。这都是关于神的物体（整体）以及它们是如何变坏的。

提取：

（主要）将类中可能独立的功能隔离开来（次要）它可以阻止使用新功能扩展类

如果您的团队真的对学术证明“上帝的对象是错误的”感兴趣，我不确定。

从心理学的角度来看，您的重构方法可能会被误解为攻击团队的能力，例如：“团队做得不好”，尽管该程序正在按预期工作。

您真正想做的是解决“ spagetti代码”和“上帝对象”的负面影响：由于副作用引起的bug增多，增加新功能的成本不菲。

提出非常具体的问题并提出问题而不是提供答案可能会更有用：

manager > Why did implement the new tax-calculation schema took more than 4 weeks
team > because {reason a}
manager > And why was {reason a}?
team > because {reason b}
manager > And why was {reason b}?
...
team > because {reason z}
manager > what could we do to avoid {reason z} ?
team > refactor code