假设有一个类执行某种类型的任务。让我们说这个任务有很多种变化。动作是相同的，只有一些参数改变（例如，对于煮熟的鸡蛋，动作=煮沸，时间= 5分钟;对于煮熟的鸡蛋，动作=煮沸，时间= 11分钟。 ，等。）。变化的参数数量约为10.
我发现有三种方法可以做到这一点：
使用开关并设置参数 代码基于类型。
将参数保存在数据库中或 文件并根据它检索它们 任务类型。
对任务进行子类化，覆盖 父类的参数和 实例化子类对象 执行有问题的任务。
第一种选择是笨拙的。但我如何决定其他两个呢？
1）从文件或数据库中检索参数。
2）对任务进行子类化。
我是否正确识别了利弊？我应该用什么其他标准来决定问题？
请指教。谢谢！
答案 0 :(得分：1)
如果仅改变参数并且算法保持不变，那么我将创建一个包含算法的不可变类，并创建该类的多个实例，每个实例具有不同的参数。将配置实例存储在常量或某些数据结构中。在伪代码中像这样：
constant SOFT_BOILED_EGG = new EggBoilingStrategy(BOIL, 5 min)
constant HARD_BOILED_EGG = new EggBoilingStrategy(BOIL, 11 min)
这也可以创建包含不同算法的子类。
很大程度上取决于您访问配置所需的方式。您可以将它们存储在地图中，这样可以轻松添加新配置。或者你可以硬编码对它们的引用。
答案 1 :(得分：0)
我认为你的CON可能会被低估为DB-parameters选项。如果可以变化的参数数量大约是10，那么你仍然可能会在拉动这些参数的例程中处理if / switch逻辑。
根据您的描述，编写子类和工厂方法的开销听起来比您在变量参数中涉及的逻辑要小。
答案 2 :(得分：0)
我的直觉说，如果对象属于逻辑上不同的类，则它们需要是物理上不同的类。
选项1对于特定问题可能是可接受的，但选项2是可行的。类应该是自定义的，不依赖于运行时数据。 （也可能有例外，但我喜欢夸张）
答案 3 :(得分：0)
我有机会在2个不同的项目上使用2个类似的系统。第一个通过子类路由，第二个通过配置路由（在我们的例子中是db）。
第一个让团队觉得他们有很多权力来定制它，因为它的子类也可能有非常具体的行为。随着时间的推移，理解系统并不是那么直接，因为这些行为隐藏在子类中。
在第二个系统上，配置非常清楚地显示了每个特定情况下对数据+行为的期望。测试课程的重点是测试他们是否能很好地处理这些设置。随着时间的推移，添加了一些基本配置，这些配置可在需要时覆盖特定功能。为了减少主类处理的代码量，一些行为被移动到特定的类，并且它们根据配置加载。
我发现第二种方法在高度动态的环境中非常强大，新的数据/对其工作方式的了解不断进入。设置/行为由类明确定义/处理，没有数据打开键系统不明白。
也就是说，这并不意味着需要在外部维护此配置。您可以轻松拥有将不同配置添加到活动配置列表的代码。如果您将它与构建器模式一起使用，给它提供默认值，那么您可以使用类似的基本配置方法而不需要那么多代码。