哪种设计模式最适合这种情况？

Question

目前，我有一个名为PolicyProvider的类，它具有以下(简写)接口：

public interface IPolicyProvider
{
    List<Policy> GetRenewalPolicies(Client client, int financialYear);
}

目的是很明显的--每年，保险都会为客户更新，他们会得到一些新的保单。

问题是，政策每年都在变化。因此，需要每年对类的具体实现进行更改(或者用大量丑陋的"if's“来评估财政年度)。我可以看到，随着时间的推移，这将变得可怕。

在这种情况下，哪种设计模式最合适？

Answer 1

按照nulliusinverbaS的建议，我将从我最初的评论中找到一个答案。

我认为这是一个工厂模式的场景，您的核心PolicyFactory (或提供者)为任何给定的客户端创建策略。

然后，您就可以拥有一个PolicyFactoryFactory类，一个工厂工厂，也就是(别提尴尬的命名)，能够为特定年份创建一个PolicyFactory (不管是PolicyFactory2012还是PolicyFactory2013等等)。

显然，这个元目录仍然能够解析外部文件并根据它们的内容构建策略(正如Florian建议的那样)。

Answer 2

避免使用"if"s的标准方法是使用子类型和动态绑定。您所需要做的就是为每个财政年度创建子类型的策略。

Answer 3

您应该使用领域模型模式，因为“策略”(特别是您已经描述过的策略)经常会发生更改，您需要使它们保持足够的隔离，以避免混淆或破坏“正常”的执行路径。

在业务行为受到大量更改的情况下，使用域模型的理由，拥有域模型将降低这些更改的总成本。将所有可能更改的业务行为封装在软件的单个部分中，可以减少执行更改所需的时间，因为所有更改都将在一个地方执行。通过尽可能地隔离该代码，我们减少了其他地方导致代码中断的可能性，从而减少了稳定系统所需的时间。