寻找一些面向对象的设计建议

我正在开发一个应用程序，该应用程序将用于在工业环境中打开和关闭阀门，并且正在考虑这样的简单操作：-

public static void ValveController
{
    public static void OpenValve(string valveName)
    {
        // Implementation to open the valve
    }

    public static void CloseValve(string valveName)
    {
        // Implementation to close the valve
    }
}

（该实现会将一些字节的数据写入串行端口以控制阀门-从阀门名称派生的“地址”，以及“ 1”或“ 0”来打开或关闭阀门）。

另一个开发人员问我们是否应该为每个物理阀创建一个单独的类，其中有几十个。我同意，最好使用PlasmaValve.Open()而不是编写类似的代码ValveController.OpenValve("plasma")，但这是否太过分了？

另外，我想知道如何最好地考虑到一些假设的未来需求：

1. 我们被要求支持一种新型的阀门，该阀门需要不同的值来打开和关闭它（不是0和1）。
2. 我们被要求支持可以设置在0-100之间的任何位置的阀，而不是简单地“打开”或“关闭”。

通常，我会在这种情况下使用继承，但是最近我开始着手解决“继承之上的组合”问题，并想知道使用组合是否有一个更好的解决方案？

如果Valve对象的每个实例都将与此ValveController运行相同的代码，那么似乎一个类的多个实例将是正确的方法。在这种情况下，只需在Valve对象的构造函数中配置它控制哪个阀门（以及如何控制）。

但是，如果每个阀门控件都需要运行不同的代码，并且当前的ValveController运行的巨型switch语句根据阀门的类型执行不同的操作，则您实现的多态性很差。在这种情况下，将其重写为具有公共基础的多个类（如果有道理），并让单一责任原则成为您的设计指南。

我的主要抱怨是使用字符串作为用于识别阀门的参数。

至少创建一个Valve具有getAddress基本实现需求形式的类，并将其传递给，ValveController并确保您不能创建不存在的阀门。这样，您就不必在每个open和close方法中处理错误的字符串。

是否创建调用打开和关闭的便捷方法ValveController取决于您，但老实说，我会将与串行端口的所有通信（包括编码）都放在一个类中，其他类将在需要时调用。这意味着当您需要迁移到新控制器时，只需要修改一个类。

如果您喜欢测试，还应该制作ValveController一个单例，以便对其进行模拟（或为操作员创建训练机）。