如何重组/重新设计不断增长的适配器类？

Question

我正在开发一个使用多个数学求解器的游戏/模拟应用程序。每个都有一个已经存在的适配器类。这些适配器类为应用程序提供所有呈现和功能信息。

从广义上讲，我们保留一个适配器对象来表示实例并调用方法来实现：

• 生成渲染数据。
• 修改对象状态。功能太多了。
• 出于各种目的阅读数据模型信息。

现在问题是这些课程在一段时间内不断增长，并且承担了太多的信息和责任。

我的问题是如何重新设计/重组这些类以使其更有意义。我应该看一下设计模式吗？

编辑：根据要求，以下是任何适配器类将要做的事情的广泛列表。

1. 与数学解算器中存储的当前数据同步。

2. 与我们的应用程序的数据模型同步。对于类似的事情     撤消/重做。

3. 修改对象状态：更改形状。这是最重要的         各种，超过50种功能来实现它。一切都是自我         包含带参数的单个服务调用。我想插入         接口和工厂在这里但功能签名不是         兼容。

4. 获取数学求解器的数据模型信息。就像getChildern一样     等

5. 更改可见性和其他图形属性。

Answer 1

使用的原则是来自GRASP的信息专家：

  

[...]使用信息专家的原则，分配职责的一般方法是查看给定的职责，确定履行职责所需的信息，然后确定信息的存储位置。信息专家将导致将责任放在课堂上，并提供实现该课程所需的最多信息。 [...]

虽然从未明确提及，但应用这一原则可能会导致您在他的重构书中使用Martin Fowler在章节Moving Features Between Objects中给出的模式：

  

[...]通常课程变得臃肿，责任太多。在这种情况下，我使用Extract Class来分离其中一些职责。如果一个类变得太不负责任，我使用Inline Class将它合并到另一个类中。如果正在使用另一个类，使用Hide Delegate隐藏此事实通常会很有帮助。有时隐藏委托类导致不断更改所有者的界面，在这种情况下，您需要使用删除中间人[...]

Answer 2

一般情况下，根据Single Responsibility Principle细分您的课程，使每个课程只有一个改变的理由。将“适配器”作为Facade放在您要提取的类上;它会使重构更顺畅。

由于您描述了所有适配器共有的职责列表，因此您可能在适配器之间拥有大量相同的代码。在完成本练习时，请尝试从多个适配器中提取相同的职责，并注意消除重复的方法。

从提取“修改对象状态”的类开始是很诱人的。由于你有超过50个（！）函数来履行这个职责，你应该把它分解成几个类，如果可以的话。因为这可能是你的适配器类中膨胀的最大原因，只是这样做可能会解决问题，尽管将其分解或者你只是移动神级而不是简化它是很重要的。

然而，这将是一项很多工作，而且可能很复杂，您不会轻易看到在适配器之间重用提取类的机会。另一方面，提取小的责任不会给你带来很多好处。我会在中间选择一些东西开始。