Question

每当使用设置向导时，用户都会回答许多不同的事情，直到可以开始真正的安装。将其与我当前项目中的类进行比较：我有一个需要多个配置步骤的类。它不适用于安装程序，但我认为安装程序向导是解释所需的更大配置功能的好方法。我正在努力寻找一个好的设计解决方案。

我目前的解决方案接近：

Flat：我可以定义一个包含所有步骤作为方法/函数/属性的大类。在调用错误的方法时，可以添加一些控制方法来抛出异常。它会完成它的工作，但程序员会因为看到这么多不同的方法而感到困惑。（ - ＆gt;他需要更多时间来了解它是如何工作的）
层次结构：我可以为每个配置步骤创建大约3个不同的类。每个都有自己的方法和功能。最后，一个类在其构造函数中需要所有3个配置类的实例。这看起来不会太混乱，因为在每个类中只能看到正确的方法。然而，程序员可能会感到恼火，小班需要这样复杂的准备，创建其他3个类。也许是嵌套类，但我认为这也是一种糟糕的编码风格。

我想知道是否有人已经遇到过这样的问题并且可以通过以下方式解决这个问题。要么为这样的问题提供合适的设计模式，要么提供一些经验/最佳实践类结构。

我已经搜索了类似的问题，检查了一些可能适合的设计模式，并且已经提供了2个方法提示，以显示答案的方向。如果您认为答案不够明确，请评论/询问缺失部分。

Answer 1

从问题和评论中解释的问题来看，“统治所有人的单一阶级”方法似乎不是一个好的选择。

也许某种策略模式是这里的方式。

您可以根据您的要求选择不同的策略，而不是单个班级的非常复杂的设置。如果你已经知道那里将会发生三种不同的事情，制定三种不同的策略。

让我们举一个例子：您想要写日志数据。也许对于文件，数据库或Web服务。

然后你对“LogWritting Strategy”只有一个依赖一个明确定义的界面，让我们说

interface ILogWriter
{
    void Write(enum LogLevel, string logEntry);
}

现在，在您的客户端代码中，您依赖于该接口并只在接口上进行调用。但是在运行时，您可以根据“配置”“注入”具体策略。

即。您只需选择适合的策略，并且您没有复杂的单个类引导。

然后你使用像

这样的具体策略

IDatabaseLogWriter
IFileLogWriter
IWebServiceLogWriter

可以在此处找到有关策略的简要说明： Strategy pattern

<强>更新

从最近的评论中我认为存储库和映射模式都可以提供帮助。

您应该考虑查看