【发布时间】：2010-03-24 22:33:52
【问题描述】：
我有一个功能性 AdjacencyListGraph 类，它遵循已定义的接口 GraphStructure。为了对此进行分层限制（例如，非循环、非空、唯一顶点数据等），我可以看到两条可能的路线，每条路线都使用 GraphStructure 接口：
创建一个类（“ControlledGraph”），该类具有一组指定各种可能限制的位标志。处理此类中的所有限制。如果新的限制要求变得明显，请更新类。
使用装饰器模式（本质上是 DI）为客户端类可能希望使用的每个单独的限制创建单独的类实现。这样做的好处是我们坚持单一职责原则。
我会倾向于后者，但天哪！我讨厌装饰器模式。它是混乱的缩影，IMO。说实话，这一切都取决于在最坏的情况下可能应用多少装饰器——到目前为止，我的数量是 7（我在这个阶段认识到的离散限制的数量）。装饰器的另一个问题是我将不得不在每个...单个...装饰器类中进行接口方法包装。呸。
如果有的话，你会选择哪一个？或者，如果你能提出一些更优雅的解决方案，那将是受欢迎的。
编辑：在我看来，将提议的 ControlledGraph 类与策略模式一起使用可能会有所帮助……某种模板方法/仿函数设置，各个位在各种图形规范接口方法中应用单独的控件。还是我输了？
【问题讨论】：
-
@Nick Wiggill：我会选择一个装饰器（它既可以用来增加职责，也可以用来减少职责），但为什么讨厌它呢？这与杂乱相反：没有装饰器，您将在 ControlledGraph 中以杂乱和厨房水槽告终。请注意，现代 IDE 可以在 one 快捷方式中生成对包装主题的所有委托调用。正确完成 OO 的要点之一是能够适应不断变化的需求。如果需求是一成不变的，那么取决于使用位域的实现（ControlledGraph）可能没问题，但这不是 OO。
-
我同意你的看法，这就是我提到 SRP 的原因。我可以告诉你，我已经有了该特定实现的半完整版本，而且它不漂亮。但是请参阅下面的答案，您会看到一个更优雅的解决方案，它封装了每个限制的功能，提供了一个更可扩展的架构，并且没有装饰器的混乱（它是混乱的——我很抱歉，但不确定的水平构造函数嵌套只是简单的愚蠢）。
标签： dependency-injection graph decorator single-responsibility-principle