0

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

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

  • 生成渲染数据。
  • 修改对象状态。有太多的功能可以做到这一点。
  • 为各种目的读取数据模型信息。

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

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

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

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

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

  3. 修改对象状态：改变形状。这是最重要的，并且有 50 多个功能来实现它。所有都是带有参数的独立的单一服务调用。我正在尝试在此处插入接口和工厂，但功能签名不兼容。

  4. 获取数学求解器的数据模型信息。比如 getChildern 等。

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

2 回答 2

2

使用的原则是来自GRASP的Information Expert：

[…] 使用信息专家的原则，分配职责的一般方法是查看给定的职责，确定履行职责所需的信息，然后确定该信息的存储位置。信息专家将导致将责任放在具有履行职责所需的最多信息的班级上。[…]

尽管从未明确提及，但应用此原则可能会引导您使用 Martin Fowler 在其重构书中的“对象间移动特征”一章中给出的模式：

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

于 2013-01-02T12:33:38.000 回答
1

一般来说，根据单一职责原则，分解你的类，使每个类只有一个改变的理由。将您的“适配器”作为您将提取的类的外观保留在适当的位置；它将使重构更顺畅。

由于您描述了所有适配器共有的职责列表，因此您可能有很多在适配器之间几乎相同的代码。在进行此练习时，请尝试从多个适配器中提取相同的职责，并寻找消除重复的方法。

从为“修改对象状态”提取一个类开始是很诱人的。由于您有 50 多个 (!) 函数来履行该职责，因此您可能应该将其分解为几个类，如果可以的话。由于这可能是适配器类膨胀的最大原因，因此只需这样做就可以解决问题，尽管分解它很重要，或者您只需移动 God 类，而不是简化它。

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

于 2013-01-02T13:06:36.193 回答