每当使用设置向导时,用户都会回答很多不同的事情,直到真正的安装启动。将其与当前项目中的类进行比较:我有一个需要多个配置步骤的类。它不适用于安装程序,但我认为安装程序向导是解释所需更大配置功能的好方法。 我想找到一个好的设计解决方案。其中'设计模式'适用于具有复杂(多步)配置的类
我目前的解决方案处理办法:
平:我可以定义与列为方法/功能/性能的所有步骤,一个大班。在调用错误的方法时,可以添加几个控制方法来抛出异常。它会做它的工作,但程序员会看到这么多不同的方法会感到困惑。 ( - >他需要更多时间来了解它是如何工作的)
层次结构:我可以为每个配置步骤创建约3个不同的类。每个人都有自己的方法和功能。最后,一个类需要在其构造函数中包含所有3个配置类的实例。这看起来不会太混乱,因为只有正确的方法在每个类中都可见。然而,程序员可能会感到烦恼,一个小班需要如此复杂的准备工作,并创建3个其他班级。也许是嵌套类,但我认为这也是一种糟糕的编码风格。
我不知道是否有人已经有这样的问题出现,可以通过回答这个..要么提供一个合适的设计模式,或者这样的问题的一些经验/最佳实践类结构。
我已经搜索了类似的问题,检查了一些可能适合的设计模式,并且已经提供了2个方法思路来展示答案可以沿着什么方向发展。如果您认为答案不够清楚,请评论/询问有关缺失的部分。
问题是有可能涉及,根据您的具体要求是什么设计模式的无限可能,确切的领域,我们不知道他们。你应该找到一个项目,在那里有一个向导阅读源代码。它们通常涉及某种状态模式。 – mpm 2013-04-07 15:55:22
如果一个类有很多事情要做,这表明已经有一些设计缺陷。你能详细解释一下这个复杂的引导过程吗?因为如果已经存在一些问题分离的问题,那么您可能会发现没有金锤可以将其转化为良好的设计。 – 2013-04-07 16:00:59
@mpm感谢您的解释。我正在使用VB.Net/C#,而不是向导的功能,一个类应该很容易使用,但是这个类需要多个配置步骤。使用状态模式,我可以为相同的方法调用更改操作,但如果方法在每个步骤中更改,那么我想我不能使用它。我在当前项目中定义了多个枚举,然后选择从数据库访问哪一个枚举。方法应该提供结果字符串列表(索引相关)。在此之后,'配置'完成,并且该类应该充当索引查找表 – Amegon 2013-04-07 16:07:31