图形限制 - 我应该使用装饰器吗？
我有一个功能性 AdjacencyListGraph 类，它遵循已定义的接口 GraphStructure。为了对此进行分层限制（例如，非循环、非空、唯一顶点数据等），我可以看到两种可能的路线，每种路线都使用 GraphStructure 接口：
创建一个类（“ControlledGraph”）它有一组位标志，指定各种可能的限制。处理此类中的所有限制。如果新的限制要求变得明显，请更新该类。
使用装饰器模式（本质上是 DI）为客户端类可能希望使用的每个单独的限制创建单独的类实现。这里的好处是我们遵守单一职责原则。
我倾向于后者，但天哪！我讨厌装饰器模式。在我看来，这是混乱的缩影。事实上，这一切都取决于在最坏的情况下可能应用多少装饰器——到目前为止，在我的装饰器中，数量是七个（我在这个阶段已经认识到的离散限制的数量）。装饰器的另一个问题是我必须在每个...单个...装饰器类中进行接口方法包装。呸。
如果有的话你会选择哪一个？或者，如果您可以提出一些更优雅的解决方案，那将受到欢迎。
编辑：我想到，使用提议的 ControlledGraph 类和策略模式可能会有所帮助...某种模板方法/函子设置，其中各个位在各种图形规范接口方法中应用单独的控件。还是我失去了情节？
I have a functional AdjacencyListGraph class that adheres to a defined interface GraphStructure. In order to layer limitations on this (eg. acyclic, non-null, unique vertex data etc.), I can see two possible routes, each making use of the GraphStructure interface:
Create a single class ("ControlledGraph") that has a set of bitflags specifying various possible limitations. Handle all limitations in this class. Update the class if new limitation requirements become apparent.
Use the decorator pattern (DI, essentially) to create a separate class implementation for each individual limitation that a client class may wish to use. The benefit here is that we are adhering to the Single Responsibility Principle.
I would lean toward the latter, but by Jove!, I hate the decorator Pattern. It is the epitome of clutter, IMO. Truthfully it all depends on how many decorators might be applied in the worst case -- in mine so far, the count is seven (the number of discrete limitations I've recognised at this stage). The other problem with decorator is that I'm going to have to do interface method wrapping in every... single... decorator class. Bah.
Which would you go for, if either? Or, if you can suggest some more elegant solution, that would be welcome.
EDIT: It occurs to me that using the proposed ControlledGraph class with the strategy pattern may help here... some sort of template method / functors setup, with individual bits applying separate controls in the various graph-canonical interface methods. Or am I losing the plot?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
啊，我现在明白了。 ControlledGraph 类中的策略模式确实是可行的方法。
每个限制都是一个离散的策略类。其中每一个都实现了整个 GraphStructure 接口，尽管大多数方法将留空（例如，非循环限制只对使用 addEdge() 来防止循环插入感兴趣，其他方法将留空）。
每次 ControlledGraph 调用其接口方法之一时，它将调用其包含的每个策略/限制的匹配方法。显然，它可能只包含每种策略中的一种。
Ah, I see it now. The strategy pattern in a ControlledGraph class is indeed the way to go.
Each limitation is a discrete strategy class. Each of these implements the entire GraphStructure interface, although most methods will be left empty (eg. an acyclic limitation is only interested in using addEdge() to prevent cycle insertions, others methods will be left empty).
Each time the ControlledGraph has one of its interface methods called, it will call the matching methods of each of the strategies/limitations it contains. It may hold only one of each type of strategy, obviously.