所以我在OO Design上相当新，我想知道Singleton设计模式的使用。我读过一些关于why singletons are bad的文章，但仍然无法弄清楚我是否需要一个。我想尽可能地避免它。
就我而言，我使用OceanOptics光谱仪，可以通过他们的API在C ++中进行控制和咨询。
我已将所有管理光谱仪的代码（发现它们，设置或获取参数，检索数据）放在一个类SpectrometerProxy中。
我想知道这个班级是否应该是单身人士。我觉得可能有一些理由可以证明这一点：
管理硬件
无论光谱仪的数量是多少，它们都通过这个类来控制和咨询
必须按照精确的顺序进行特定的程序，并且只需执行一次（打开光谱仪，检查一些变量，并在程序停止时关闭光谱仪）
然后，我不知道是否有更好的方法来实现这个类而不是使它成为单例。我想到的另一个解决方案是将它保留为普通类但是阻止复制（通过声明复制构造函数和赋值运算符私有）并只是将指针传递给需要它的类：它不会阻止创建多个{{1}我希望避免这种情况。
我还想过将它全部静态化，但是它会依赖客户端代码以正确的顺序调用正确的静态成员函数（并且不会忘记正确关闭与光谱仪的连接），因此会出错 - 违反RAII原则。
那么，对于这个问题，单例是一种可能的正确设计方法，还是应该将其排除并搜索其他方法？
答案 0 :(得分：4)
这主要是宗教主题：使用或不使用单身人士。根据我使用硬件（10年以上）的经验，我宁愿不使用它们。第一：as Murphy's law明天说你需要使用一个以上的光谱仪。第二：最好使用需要与硬件交互，从中继承并编写代码的方法创建虚拟抽象接口，实际处理硬件。当您无法访问硬件但需要调试应用程序时，这种方法很有用。在这种情况下，您只需继承该接口并创建模拟函数（或更好的函数，从数据中读取实际数据，从硬件中获取数据），但程序的其余部分保持不变。
答案 1 :(得分：2)
我认为你应该问自己的问题是为什么你需要一个单独的类而不是你怀疑在任何地方你只有一个光谱仪（例如由于成本），在这种情况下，它比一个单独的更为重要出于任何软件设计原因。 On Design Patterns: When to use the Singleton?涵盖了为什么你可能想要一个单身人士，What is so bad about singletons?涵盖了单身人士的消极方面。就个人而言，我不是单身模式的忠实粉丝，除非情况从软件角度实际要求它，否则其他任何事情都可能导致未来的代码重新考虑。
答案 2 :(得分：1)
除了单身决定之外，我认为只需一个班级来发现设备和控制单个设备是一个坏主意 - 你将不同的功能放在同一个类中，没有明显的理由。
很难说不知道更多，但总的来说将功能分成不同的类可能更有意义：
HwLookup - 执行设备发现等。这可能是一个单身人士，但我不确定我会这样做 - 我没有看到任何使其成为单身人士的特殊原因，但这可能有意义。它返回SpectrometerProxy（或仅Spectrometer）代表单个设备，可用于设置/获取参数，检索测量结果等。）根据它做了多少东西，我甚至不确定我是否将HwLookup设计为一个类：它可以是一个函数（例如，如果它只是返回一个光谱仪代理列表）。没有理由把所有东西都放在c ++代码中。