我试图将策略模式应用于特定情况，但遇到了如何避免将每个具体策略耦合到为其提供数据的上下文对象的问题。以下是模式的简化情况，该模式以几种不同的方式发生，但应以类似的方式处理。

我们有一个对象Acquisition它提供与特定时间框架相关的数据 - 基本上是使用不同硬件收集的一堆外部数据。由于它包含的数据量，它已经太大了，所以我不想再赋予它任何进一步的责任。我们现在需要获取一些数据，并根据某些配置向硬件发送相应的电压。

因此，想象一下以下（非常简化的）类：

class Acquisition
{
    public Int32 IntegrationTime { get; set; }
    public Double Battery { get; set; }
    public Double Signal { get; set; }
}

interface IAnalogOutputter
{
    double getVoltage(Acquisition acq);
}

class BatteryAnalogOutputter : IAnalogOutputter
{
    double getVoltage(Acquisition acq)
    {
        return acq.Battery;
    }
}

现在，每个具体策略类都必须与我的 Acquisition 类耦合，这也是最有可能修改的类之一，因为它是我们应用程序的核心。这仍然是对旧设计的改进，旧设计是一个巨大的 switch 语句inside the Acquisition班级。每种类型的数据可能有不同的转换方法（虽然电池是一个简单的传递，但其他的则根本没有那么简单），所以我觉得策略模式或类似的应该是要走的路。

我还要指出的是，在最终的实施中，IAnalogOutputter将是一个抽象类而不是一个接口。这些类将位于用户可配置的列表中，并序列化为 XML 文件。该列表必须在运行时可编辑并被记住，因此可序列化必须是我们最终解决方案的一部分。万一它有所作为。

如何确保每个实现类都能获取其工作所需的数据，而不将其绑定到我最重要的类之一？或者我是否以完全错误的方式处理此类问题？

Strategy Pattern封装通常很复杂的操作/计算。

您想要返回的电压取决于

• 配置件
• Some采集数据的

所以我会将它们放入另一个类中并将其传递给策略实施者。

同样在序列化方面，您没有序列化策略类，也许只有它们的名称或类型名称。

UPDATE

好吧，看来您的实现只需要一份采集数据。这对于策略模式来说有点不寻常 - 但我不认为它适合Visitor更好，所以策略很好。我将创建一个类，除了实现者需要的配置之外，它还具有属性、获取数据（可能继承自它）。