0

我有一个功能性 AdjacencyListGraph 类，它遵循定义的接口 GraphStructure。为了对此进行分层限制（例如，非循环、非空、唯一顶点数据等），我可以看到两条可能的路线，每条路线都使用 GraphStructure 接口：

  1. 创建具有一组指定各种可能限制的位标志的单个类（“ControlledGraph”）。处理此类中的所有限制。如果新的限制要求变得明显，请更新类。

  2. 使用装饰器模式（本质上是 DI）为客户端类可能希望使用的每个单独的限制创建一个单独的类实现。这样做的好处是我们坚持单一职责原则。

我会倾向于后者，但天哪！，我讨厌装饰器模式。它是混乱的缩影，IMO。老实说，这一切都取决于在最坏的情况下可能应用多少装饰器——到目前为止，我的数量是 7（我在这个阶段认识到的离散限制的数量）。装饰器的另一个问题是我将不得不在每个...单个...装饰器类中进行接口方法包装。呸。

如果有的话，你会选择哪一个？或者，如果您可以提出一些更优雅的解决方案，那将是受欢迎的。

编辑：在我看来，将建议的 ControlledGraph 类与策略模式一起使用可能会有所帮助......某种模板方法/仿函数设置，各个位在各种图形规范接口方法中应用单独的控件。还是我失去了情节？

4

1 回答 1

0

啊，我现在看到了。ControlledGraph 类中的策略模式确实是要走的路。

每个限制都是一个离散的策略类。这些中的每一个都实现了整个 GraphStructure 接口，尽管大多数方法将留空（例如，非循环限制只对使用 addEdge() 来防止循环插入感兴趣，其他方法将留空）。

每次 ControlledGraph 调用它的一个接口方法时，它都会调用它包含的每个策略/限制的匹配方法。显然，它可能只持有每种策略中的一种。

于 2010-03-24T23:02:09.847 回答