图形限制 - 我应该使用装饰器吗？

我有一个功能AdjacencyListGraph类遵守定义的接口GraphStructure。为了层上这一（例如无环的，非空的，独特的顶点数据等。），I可以看到两个可能路线，每一个利用所述GraphStructure接口的限制：图形限制 - 我应该使用装饰器吗？

创建单个类（ “ControlledGraph”），它具有一组指定各种可能限制的位标记。处理这个类的所有限制。如果新的限制要求变得明显，更新课程。
使用装饰模式（DI，本质上）为客户类可能希望使用的每个单独的限制创建单独的类实现。这样做的好处是我们坚持单一责任原则。

我会倾向于后者，但通过Jove !,我讨厌装饰者模式。这是混乱的缩影，海事组织。事实上，这完全取决于在最糟糕的情况下可能会应用多少装饰器 - 到目前为止，计数是七（我在此阶段已经认识到的离散限制的数量）。装饰器的另一个问题是，我将不得不在每个...单个装饰器类中进行接口方法包装。呸。

你会去哪，如果？或者，如果你能提出一些更优雅的解决方案，那将是值得欢迎的。

编辑：在我看来，使用建议的ControlledGraph类与战略模式可能有助于这里...某种模板方法/函子设置，与各个位应用单独的控件在各种图形 - 规范接口方法。还是我失去了阴谋？

来源

2010-03-24 Arcane Engineer

@尼克Wiggill：我会去装饰（可用于添加和不知道，删除责任），但为什么恨它？这与杂乱的反面相反：没有装饰者，你会在你的ControlledGraph中出现混乱和厨房水槽。请注意，现代IDE可以以* one *快捷方式生成对包装主题的所有委托调用。 OO正确完成的一个重点是能够适应不断变化的需求。如果需求被刻在石头上，那么取决于使用位域的实现（ControlledGraph）可能没问题，但这不是OO。 – SyntaxT3rr0r 2010-03-24 22:48:04

我同意你的看法，这就是我提到SRP的原因。我可以告诉你，我已经有了这个特定实现的半完整版本，并且它不是很漂亮。但看到我的答案在下面，你会看到一个更优雅的解决方案，它封装了每个限制的功能，提供了一个更加可扩展的体系结构，并且没有装饰器的混乱（它是混乱的 - 我很抱歉，但未定级别的构造函数嵌套只是简单的愚蠢）。 – 2010-03-24 23:06:43

啊，我现在看到它。 ControlledGraph类中的策略模式的确是一种可行的方式。

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

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

来源

2010-03-24 23:02:09

图形限制 - 我应该使用装饰器吗？

回答

相关问题