oop - 哪种“设计模式”适合具有复杂（多步骤）配置的类

Question

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

我目前的解决方案方法：

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

我想知道是否有人已经遇到过这样的问题并且可以通过......提供合适的设计模式，或者针对此类问题提供一些经验/最佳实践类结构。

我已经搜索了类似的问题，检查了一些可能适合的设计模式，并且已经提供了 2 种方法思路来说明答案的方向。如果您认为答案不够清楚，请评论/询问缺少的部分。

score 1 · Accepted Answer

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

也许某种策略模式是要走的路。

您可以根据自己的要求从不同的策略中进行选择，而不是对单个班级进行非常复杂的设置。如果您已经知道可能会发生三种不同的事情，请制定三种不同的策略。

举个例子：你想写日志数据。可能是文件、数据库或网络服务。

那么你只有一个对“LogWritting Strategy”的依赖，它有一个明确定义的接口，可以说

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

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

即，您只需选择适合的策略，而无需对单个类进行复杂的引导。

然后你使用具体的策略，比如

IDatabaseLogWriter
IFileLogWriter
IWebServiceLogWriter

可以在此处找到有关什么策略的简要说明：策略模式

更新

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

你应该考虑看看

1 回答 1