上位机开发过程中的设计模式体会(1)：工厂方法模式、单例模式和生成器模式
简介
在我的 QT/C++ 开发工作中，合理运用设计模式极大地提高了代码的可维护性和可扩展性。本文将分享我在实际项目中应用的三种创造型模式：工厂方法模式、单例模式和生成器模式。
1. 工厂模式 (Factory Pattern)
应用场景
在我的 QT 项目中曾经有一个需求，需要我针对不同的手机类型输出不同的对象，针对不同的测试机台生成不同的治具，在对应的testItem中，针对不同的手机类型和测试治具，做出不同的动作。
以下是我认为其中可贵的特点：
1.将生成的类型的参数作为配置输入，无论是json或者是xml或者是.ini，在不同的产线维持不同的配置即可
2.在start the test flow时，实时load配置，动态生成测试对象和测试治具的对象
特点
- 优点：
符合开闭原则（新增新手机和新治具只需添加新工厂即可）
单一职责原则。 可以将产品创建代码放在程序的单一位置， 从而使得代码更容易维护。
可以避免创建者和具体产品之间的紧密耦合。
新对象生成只依赖配置文件，避免代码的修改
- 缺点：
应用工厂方法模式需要引入许多新的子类， 代码因此变得更复杂
2. 单例模式 (Singleton Pattern)
应用场景
项目中需要使用串口来向光源控制板发送指令来控制灯光，对于一个串口设备来说，我既没有被其他对象重新创建同时使用的场景，也不能破坏串口的独占性，因此使用了单例模式来创建light source类，避免代码冗余和被误new的风险；同时，我的所有的对象共享同一个日志类，因为我暂时没有同时创建多个日志文件来记录程序日志的需求
特点
- 优点：确保全局唯一实例，提供统一的访问点
- 缺点：可能导致代码耦合度高，难以测试
- 我的实际应用：我使用单例模式管理日志系统和独享的设备，确保这些关键资源在应用中只有一份实例
3. 生成器模式 (Builder Pattern)
应用场景
项目中需要使用不同的SCPI设备，根据不同的配置生成对应的对象；因此我在DeviceManager中新建了一个fixtureBuilder类，读取我的excel配置文件，使用生成器模式生成对应的治具设备；成为devicemanager类的成员变量；
特点
- 优点：
可以分步创建对象， 暂缓创建步骤或递归运行创建步骤。
生成不同形式的产品时， 你可以复用相同的制造代码。
单一职责原则。 你可以将复杂构造代码从产品的业务逻辑中分离出来。
- 缺点：
增加了代码复杂度，对于简单对象可能过度设计
总结
在QT/C++开发实践中，这三种创建型模式各有其适用场景：
- 工厂模式：当需要创建一系列相关或相似对象时使用
- 单例模式：当需要确保全局唯一实例时使用
- 生成器模式：当需要构造复杂对象且构造过程需要灵活性时使用
通过合理应用这些模式，代码变得更加模块化、可维护性更高。在后续文章中，我将继续分享结构型模式和行为型模式在QT项目中的应用。