如何使策略模式可维护而不损害它？

Question

我正在努力满足我所有要求的设计

我有一组算法，可以单独执行，也可以组合成各种配置以产生附加输出。

1. 这些算法可能会很昂贵，并且如果运行一次，则应将结果兑现以备后用。

2. 该算法可以在不同的上下文中使用。

3. 这些算法应该开放以进行扩展，以便它们能够跟上年度标准修订的要求。

4. 设计应可维护

我为满足这些要求的第一个尝试是将策略模式与以下设计一起使用...



行为计算的输出缓存在行为本身中。

此满足要求1,2,3，但不满足4。

对CalculateOutput（）的调用需要30个不同的参数，它是自己的，并且是允许其调用其他具体行为的必要参数。对一个功能的参数进行更改会产生连锁反应，并经常导致所有行为都必须更新其参数列表。

此外，由于行为之间并不总是存在1：1映射，因此缓存系统无法正常工作。例如，要从EnergyBehaviour生成输出，它需要执行多个调用NHSolarPosition。 “ NHSolarPosition”如何只为一个缓存的“ outPut_”缓存多个“ angleOfIncidence _”？

我试图通过将所有参数封装在它们自己的类型“ PVPanel”中，并将其传递给行为来解决上述问题。由于两个原因，这是有问题的。首先，调用简单行为会产生大量开销，因为可能只需要几个参数，但是还有许多其他未被使用或相关的参数。其次，将“ PVPanel”类型传递给行为会导致要求2失败，我无法在与PVPanels无关的上下文中使用行为。

我正在努力将我的所有要求统一为一个优雅的设计。

Answer 1

我不确定您的行为类是否表示一个函数及其参数，是否使用一个行为实例并为不同的调用更新其属性。您仍然可以在您的行为中缓存多个调用，但是将缓存从这里移走而不是让这些系统的用户负责可能会更简单。

我应该补充说，在给定系统状态的情况下，如果您总是会得到相同的结果以进行输出计算，则只希望进行缓存。给定模型中的不同状态，对于这些行为之一，您能否从相同的输出中获得不同的结果？

对您的问题的评论建议使用std::map参数。另一种选择是为计算指定特定的参数类别。查看访问者模式或std::variant，以了解如何包装这些特定的参数类型。

std::map可能会更容易，因为它可以解决有关PVPanel和要求2的问题。这只是从std::map实例或任何其他类型填充PVPanel的情况。或者，您可以使用PVPanel类型的访问器，然后将它们上移到PVPanel和其他未来类型实现的接口中。