问题标签 [god-object]

我知道当你有一个只能在一个地方使用的类对象时，这是糟糕的编程和架构。但是我也被警告过要创建一个功能强大且可以做太多事情的对象。那么我该如何分解呢？这是我的意思的一个例子——请不要把这些东西从字面上理解，因为这只是一个例子。

无论如何，我有一个我正在使用的对象，它相当复杂。很多信息都存储在这个对象中，它可以对数据执行很多操作。所以，我们称这个物体为地球。

到目前为止很简单。但我可以继续处理对象可能执行的许多事情。因此，为了避免事情变得过于复杂，我通过创建另外两个对象来分解白天和晚上发生的“活动”：白天和黑夜（这两个未显示）。所以现在我有一个更新的 Planet 课程。

现在，这两个类 - Day 和 Night - 将永远不会在 Planet 类之外使用。这是为这个“父”类Planet组织我的方法和属性的好方法吗？我还能如何整齐地组织类似的东西？

我读过关于重构的文章，但我认为这对我的情况没有帮助。我喜欢我可以像这样调用 Planet 对象的想法：Earth.Night.BlowUpMoon.

我有一个有很多现有代码的 Servlet。我正在尝试将依赖注入添加到其中的一部分。目前我正在手动进行：

这里 book 和 offer 存储库依赖项通过构造函数注入到 BookPriceAdjuster 中。getBookPriceAdjuster 方法允许从 AdjustBookPriceHandler 继承的类提供不同的价格调整器。

我想开始使用像 Guice 这样的 DI 框架来减少复杂示例会引入的一些样板代码。但是，我不确定在这种情况下使用它的最佳方式。

我如何编写能够从“上帝”对象 RequestState 和 RequestData 中提取相关依赖项的绑定？或者此时使用框架会同样复杂和混乱？

类太大，难以处理。在Objective-C中，我很想使用类别来分解班级，但是：类别不只是将一个装满了太多垃圾的房子分成几个房间吗？我想，同样的问题也适用于 C# 中的部分类。

在什么情况下可以使用类别来解决“类太大”的代码异味？什么时候不正确，班级真的需要“重组或分解成更小的班级”？

我一直在阅读很多提倡胖模型和瘦控制器方法的博客，尤其是。Rails 营地。结果，路由器基本上只是弄清楚在什么控制器上调用什么方法，而所有控制器方法所做的就是调用模型上的相应方法，然后调出视图。所以我在这里有两个我不明白的问题：

1. 控制器和路由器实际上并没有做太多不同的任务，只是在基于路由的上帝模型上调用一个方法。
2. 模特做的太多了。发送电子邮件、创建关系、删除和修改其他模型、排队任务等。基本上，现在您拥有神一样的对象，它们应该完成所有可能与建模和处理数据有关的事情。

你在哪里画线？这不就是掉入神模式了吗？

我正在使用 SFML API 在 C++ 中开发 2D 游戏，但我遇到了类设计问题。我认为我违反了 SRP（单一责任原则），因为我有一个名为“游戏”的主类应该处理窗口。它包含一个包含主游戏循环的方法。现在的问题；它包含超过5个类的对象（组合），例如Player、Menu、SplashScreen。您认为创建这样的“上帝”类是一个好主意吗？你知道我可以从中学习的任何开源 C++ 2D 游戏吗？先感谢您。

我在一个相当大的产品上工作。它一直在开发中，因为 .Net 1.0 仍在进行中，所以它有很多质量差的代码，并且没有考虑到单元测试。现在我们正在努力提高质量并为每个功能和错误修复实施测试。我们现在遇到的最大问题之一是依赖地狱和上帝对象。有一个特别糟糕的上帝对象：Session。基本上，与程序当前会话相关的任何内容都在此对象中。还有一些其他的神物。

无论如何，我们通过使用 Resharper 从中提取接口，使这个上帝对象“可模拟”。然而，这仍然使测试变得困难，因为大多数时候您必须查看您编写的代码，以从 100 种不同的方法和属性中找出真正需要模拟的内容。

现在仅仅拆分这个类是不可能的，因为实际上有成百上千个对这个类的引用。

因为我有一个接口（并且几乎所有代码都被重构为使用该接口），所以我有了一个有趣的想法。如果我让ISession接口继承自其他接口怎么办。

例如，如果我们有这样的事情：

这样，使用 ISession 的现有代码不必更新，实际实现也不必更新。但是，在我们编写和重构的新代码中，我们可以使用更精细的 IFoo 或 IBar 接口，但传入一个 ISession。

最终，我认为这可能更容易最终分解实际的 ISession 和 Session 上帝接口/对象

现在给你。这是测试这些上帝对象并最终分解它们的好方法吗？这是记录在案的方法和/或设计模式吗？你做过这样的事吗？

有谁知道重构上帝对象的最佳方法？

它不像将其分解为许多较小的类那么简单，因为存在高度的方法耦合。如果我退出一种方法，我通常最终会退出所有其他方法。

事情是这样的：

我最近加入了一个 webapp 项目，该项目按照标准维护一个全局可用的（即其本身的属性window）对象，该对象包含作为属性或递归子属性的所有函数和变量，以运行应用程序——包括所有小部件的状态指示符、初始化别名、通用 DOM 操作方法——一切。我会尝试用简化的伪代码来说明，但这违背了我的关注点，即这东西是独一无二的。基本上没有任何东西是封装的：所有单个粒度组件都可以从任何地方读取或修改。

我想要的方式：

在我最近的工作中，我一直是高级或唯一的 Javascript 开发人员，因此我能够以一种使用函数的风格编写代码，通常立即调用/自动执行，用于确定离散代码块的范围并将粒度原语作为变量保留在这些代码块中范围。使用这种模式，默认情况下，所有内容都锁定在其执行范围内，偶尔会在需要公开 API 的情况下返回一些明智选择的 getter/setter 函数。

... B 在通用级别上是否比 A 性能更好？

将代码重构为从样式 A 到样式 B 的功能奇偶性是一项艰巨的任务，因此我无法对我的断言进行任何有意义的实际测试，但与作用域函数样式相比，Monolithic God 对象反模式是否是一个已知的性能怪物? 为了易读性、代码安全和关注点分离，我会为 B 辩护......但我想将所有内容一直保存在内存中，通过查找链等进行爬行，这将使其成为访问任何内容的固有性能密集型练习，或者至少使垃圾收集成为一项非常困难的任务。

昨天在玩电子游戏的时候突然想到一个问题，游戏保存机制是怎么实现的？

大多数情况下，保存需要游戏的所有数据。在这种情况下，程序员不是必须制作一个引用每一个游戏数据的上帝对象吗？

我在这里发布问题而不是游戏开发，因为我想要基于软件设计而不是游戏开发本身的答案。

我的游戏有很多子系统。他们可以互相使用。早些时候，我正在初始化子系统引用并将其存储到静态 Game 对象中，而不是制作单例。现在我看到 Game 对其他类的引用太多，看起来很混乱：

我能处理什么呢？我不需要这些子系统的抽象。而且我认为单例并不适合这种情况 - 架构看起来被分割成碎片。我想从一个地方以正确的顺序初始化我的所有子系统。但是引用的类太多了...

添加
查看 DI - 我可以将依赖项发送到类构造函数并初始化静态工厂中的每个类。这就是我要找的。
但是我刚刚意识到我的问题是，当我尝试使用 Unity3D 对象组件架构时，我无法将依赖关系发送到构造函数，因为类初始化是从 UnityEngine 调用的。
所以在这种情况下，我需要 Singleton 或 Blob 来保留引用。如果我抛弃 Unity 架构，那么我将从构造函数获取所有依赖项，并且不需要单例或 blob。
我需要重新设计我的架构，UnityEngine 不会创建需要获取子系统引用的对象，而是从我的代码中创建这些类，并让他们创建和管理他们的 UnityEngine“游戏对象”。