这是策略模式吗？

Question

一点背景：

在我正在开发的系统中，有各种类型的CSV文件需要读取并将内容保存在不同的数据库表中。由于这是关于根据输入改变行为，我研究了装饰器和策略模式，并为我的系统提出了以下解决方案。

首先我创建了以下接口。

• ICDRMapper从给定的CSV文件中读取每一行，并在运行验证/修改（如果有）后映射到对象。每种CDR类型都有许多具体实现。

• ICDRReader获取输入的CSV文件并读取每一行并将其传递给映射器。每个阅读器实现都使用MEF元数据进行修饰，以便ICDREngine可以动态定位正确的元数据。该接口还为每种CDR类型提供了许多实现。

• ICDREngine实现使用MEF元数据来查找匹配的ICDRReader实现。这通常只有一个实现。

然后，我创建了一个AbstractCDRReader和AbstractCDRMapper并使用了装饰器模式将特定实现委托给不同的具体类。

AbstractCDRReader选择基于MEF元数据的正确ICDRMapper实现，就像引擎一样。

以下是生成的类图。

所以我的问题是，

• 这种策略模式还是不同的？

• 我有什么方法可以改进这个设计，以便下次我需要阅读一个全新的不同CSV文件时，我可以很快完成实现吗？

  < / LI>

Answer 1

选择一个架构不应该过多地关注设计模式，而应该关注逻辑思维。 您是否认为您提供的内容可以轻松扩展到新类型的CSV文件？如果您确实忘记了它是哪种模式，并确保您可以坚持您的设计，那么能够解释对队友的决定。

话虽如此，它很可能是Builder模式。从模式中可以看出，映射器的最终产品是什么，但我认为可以应用构建器。

基本上，AbstractMapper是Builder部分，具体的地图制作者是ConreteBuilder，您的架构中肯定还有一些Director。它甚至听起来像建设者。 “我有一个输入数据。我需要负责根据各种参数解析它并在我的应用程序的其余部分创建一个产品。”当你想到它时，你基本上是在构建一些东西，获取不熟悉的数据并构建已知对象 - 它会导致创建模式。

至于读者，它可能是相同的，它可以通过策略或其他东西。这取决于你如何看待它以及它实际上在做什么。

Answer 2

它可能是模式的组合。我想我们缺少有关如何决定在Mobile，ADSL和Fixed之间切换的信息。最强的适合似乎是抽象工厂：

https://en.wikipedia.org/wiki/Abstract_factory_pattern

重要的是要记住模式不是独占的，在编写好的OO代码时，你可能会巧妙地使用其他模式的元素。

Answer 3

您已经描述了系统某个部分的体系结构。它使用很少的设计模式：

• 抽象工厂（ ICDREngine 创建 ICDRReader ， ICDRMapper 的具体实现的过程），
• 策略 patern的两个实现（ ICDRReader ， ICDRMapper 层次结构），
• 你还提到了装饰者（虽然我没有从类图中看到它 - 它要么不完整，要么你误解了所谓的Decorator）。
• 如果我没弄错的话，Mapper和Reader层次结构之间的关系代表 Bridge 模式。

至于我，你的建筑看起来很好而且灵活。我不确定您希望改进哪些内容以便更轻松地添加读取新CSV格式的功能 - 目前您只需要添加新的ICDRReader实现，不是吗？所以从我的观点来看这很容易，对于这个特殊的“问题”，没有什么可以改进的。