系统架构设计师论文分享-论设计模式的应用

论设计模式的应用

摘要

2023 年 9 月，我司立项研发纱线 MES 系统，为国内纱线工厂提供 SaaS 服务，助力工厂数字化、智能化升级。我在项目中担任系统架构设计师，主导架构设计工作。鉴于系统模块繁多、业务独立且需适配灵活的业务变更与扩展需求，架构组决定引入工厂模式、观察者模式、策略模式等经典设计模式。通过设计模式的合理应用，有效降低了模块间耦合度，提升了代码可维护性与系统扩展性，保障了多业务场景下的高效协同，成功支撑系统按时上线。目前已有 563 家工厂接入系统，运行稳定，充分验证了设计模式在复杂微服务架构系统中的实践价值。

项目背景

随着中国制造产业升级与工厂数字化、智能化的深度发展，我所在的某地纺织科技公司基于自研物联网平台，先后推出染整一体化和织布一体化平台，凭借优质的服务与显著的应用效果，获得纱线工厂的广泛认可，也为公司带来了丰厚的经济回报。为进一步完善纺织行业数字化解决方案，覆盖纱线生产全流程，公司于 2023 年 2 月启动纱线 MES 系统研发项目，项目预算 730 万，建设工期 10 个月。
该系统涵盖纱线工厂从清花、梳棉、并条、精梳、粗纱、细纱到络筒的全流程工序，旨在提供全面的生产管理解决方案。系统采用物联网层次架构模型，分为感知层、网络层和应用层。其中，网络层复用公司已有的物联网平台，感知层与应用层为本次重点建设内容：感知层采用 Golang 语言开发，以联网网关形式部署在工厂侧，负责生产数据采集与云端指令下发；应用层作为系统主体，采用 Java 语言开发，基于 Spring Cloud 微服务架构搭建，数据库选用 Mysql，缓存采用 Redis，前端使用 vue.js 框架，日志、监控及链路追踪依托 skywalking、prometheus、grafana 和 ELK 实现，最终通过 DevOps 方式部署在 Kubernetes 集群中。系统上线后，将提供基础管理、数据接入、工单排产、数字孪生、工资计算、智控中心、数据分析等核心功能，覆盖生产全流程的管理需求。通过这些功能的协同应用，将全面提升纱线工厂的数字化运营水平与生产效率，推动其实现从传统生产模式向智能化生产模式的转型。

设计模式的选择与应用

纱线 MES 系统涉及数十个业务模块，各模块既相互独立又存在频繁的数据交互，且需应对后期业务流程优化、新功能拓展等需求。若采用传统开发模式，易导致代码耦合度高、维护困难、扩展受限等问题。基于此，架构组经过充分论证，决定引入工厂模式、观察者模式、策略模式三种经典设计模式，分别解决对象创建、状态联动、算法切换等核心场景的问题。

1、工厂模式

工厂模式是一种创建型设计模式，其核心思想是定义一个创建对象的接口，将对象的创建逻辑封装在具体的工厂类中，客户端无需关注对象的创建细节，仅通过工厂类即可获取所需对象。该模式的优势在于降低了对象创建与使用的耦合度，便于统一管理对象创建逻辑，当对象创建规则发生变化时，仅需修改工厂类，无需改动客户端代码，大幅提升了系统的可维护性。在纱线 MES 系统中，订单、工单、设备任务等对象的创建场景频繁，且不同类型的对象创建逻辑存在差异（如订单需区分加急订单、常规订单，工单需适配不同生产工序）。若直接在业务代码中实例化对象，会导致创建逻辑与业务逻辑混杂，后续修改创建规则时需逐一修改相关业务代码，效率低下且易出错。为此，我们采用工厂模式对对象创建逻辑进行重构：首先定义统一的对象接口（如 OrderInterface、WorkOrderInterface），明确对象的核心方法；然后针对不同类型的对象，实现对应的具体类（如 UrgentOrder、NormalOrder、CardingWorkOrder、SpinningWorkOrder）；最后创建专门的工厂类（OrderFactory、WorkOrderFactory），根据客户端传入的参数（如订单类型、工序类型），动态创建对应的对象并返回给客户端。例如，在工单排产模块中，当用户发起排产请求时，仅需传入生产工序（如梳棉、细纱）和订单类型，排产服务无需关注具体工单对象的创建逻辑，直接调用 WorkOrderFactory 的 create 方法即可获取适配的工单对象，后续仅需调用工单对象的统一接口完成排产流程。这种设计不仅简化了业务代码，还使系统能够快速适配新的订单类型或生产工序 —— 只需新增对应的具体类和工厂类中的创建逻辑，无需修改现有业务模块，极大提升了系统的扩展性。

2、观察者模式

观察者模式是一种行为型设计模式，定义了对象间的一对多依赖关系，当一个对象（被观察者）的状态发生变化时，所有依赖它的对象（观察者）都会收到通知并自动更新。该模式的核心价值在于实现了被观察者与观察者的解耦，双方仅通过抽象接口交互，互不依赖具体实现，便于灵活扩展观察者类型。在纱线 MES 系统中，存在大量 “状态变更需联动多个模块更新” 的场景。例如，生产设备的运行状态（正常、故障、停机）变更后，需要同步更新监控模块的设备状态显示、报表模块的生产数据统计、智控中心的大屏展示以及工资计算模块的工时统计；又如，工单的生产进度（待生产、生产中、已完成）变更后，需同步更新排产模块的任务状态、数字孪生模块的生产流程模拟以及数据分析模块的效率分析结果。若采用传统的硬编码方式，在设备状态或工单进度变更的代码中直接调用各个模块的更新方法，会导致模块间耦合度极高 —— 新增一个需要联动的模块时，需修改原有状态变更代码，违反了 “开闭原则”，且易引发连锁错误。为解决这一问题，我们引入观察者模式进行设计：首先定义被观察者接口（Subject），包含注册观察者、移除观察者、通知观察者的抽象方法；定义观察者接口（Observer），包含接收通知后执行更新操作的抽象方法。然后，将设备状态、工单进度等需要被监控的对象封装为具体被观察者类（如 EquipmentSubject、WorkOrderSubject），实现 Subject 接口，内部维护观察者列表，并在自身状态变更时，遍历观察者列表并调用其更新方法。同时，将监控模块、报表模块、智控中心等需要接收通知的模块封装为具体观察者类（如 MonitorObserver、ReportObserver、ControlCenterObserver），实现 Observer 接口，在更新方法中编写各自的业务处理逻辑。例如，当生产设备发生故障时，EquipmentSubject 会首先更新自身状态为 “故障”，然后调用 notifyObservers 方法，向所有注册的观察者（MonitorObserver、ReportObserver 等）发送故障通知及设备信息。各观察者收到通知后，自动执行各自的更新逻辑：MonitorObserver 更新设备状态显示并触发报警提示，ReportObserver 暂停该设备的生产数据统计并记录故障时长，ControlCenterObserver 在大屏中高亮显示故障设备位置。通过这种设计，被观察者与观察者完全解耦，新增一个需要联动的模块时，仅需创建新的观察者类并注册到对应的被观察者中，无需修改原有代码；同时，若某个观察者的更新逻辑发生变化，也不会影响其他观察者或被观察者，大幅提升了系统的维护效率和稳定性。

3、策略模式

策略模式是一种行为型设计模式，定义了一系列算法族，将每个算法封装起来并使它们可相互替换，让算法的变化独立于使用算法的客户端。该模式的核心是通过抽象策略接口隔离算法的定义与使用，客户端可根据具体需求动态选择不同的算法实现，无需关注算法的内部逻辑。在纱线 MES 系统中，多个模块存在 “同一业务目标需多种实现方式” 的场景。例如，工单排产模块需支持不同的排产策略 —— 针对加急订单的 “优先级排产策略”、针对设备负载均衡的 “均衡排产策略”、针对生产成本优化的 “成本最优排产策略”；工资计算模块需支持不同的计薪策略 —— 按计件工资的 “产量计薪策略”、按工时的 “计时计薪策略”、针对技术工种的 “技能等级计薪策略”；质量检测模块需支持不同的检测策略 —— 针对关键工序的 “全检策略”、针对常规工序的 “抽样检测策略”、针对原材料的 “批次检测策略”。若将这些不同的策略逻辑混杂在业务代码中，会导致代码冗长、逻辑混乱，且新增或修改策略时需修改原有业务代码，维护难度极大。为此，我们采用策略模式进行优化设计：首先定义策略接口（如 SchedulingStrategy、SalaryCalculationStrategy），包含策略执行的抽象方法（如calculate、execute）。然后，针对每种具体策略，创建对应的策略实现类（如 PrioritySchedulingStrategy、BalanceSchedulingStrategy、PieceworkSalaryStrategy），实现策略接口，封装各自的算法逻辑。最后，在使用策略的客户端模块（如排产服务、工资计算服务）中，引入策略接口作为依赖，通过构造函数或 set 方法动态注入具体的策略实现类，客户端仅需调用策略接口的抽象方法即可执行对应的算法，无需关注具体策略的实现细节。例如，在工资计算模块中，工资计算服务依赖 SalaryCalculationStrategy 接口，当计算员工工资时，服务会根据员工的岗位类型（如一线操作工、技术工），通过策略工厂动态获取对应的计薪策略实现类并注入，然后调用其 calculate 方法完成工资计算。若后续需要新增 “绩效挂钩计薪策略”，仅需新增对应的策略实现类，无需修改工资计算服务的核心逻辑；若需要调整某类岗位的计薪规则，仅需修改对应的策略实现类，不会影响其他岗位的计薪流程。这种设计使系统能够灵活适配不同的业务需求，降低了策略变更对系统的影响，同时让代码结构更清晰、职责更明确。

总结

在纱线 MES 系统的架构设计与开发过程中，工厂模式、观察者模式、策略模式的合理应用，有效解决了系统模块耦合度高、可维护性差、扩展性不足等核心问题，为系统的稳定运行和持续迭代提供了坚实的架构支撑。通过工厂模式优化对象创建逻辑，简化了业务代码并提升了扩展性；通过观察者模式实现状态变更的联动更新，降低了模块间耦合；通过策略模式封装不同业务算法，使系统能够灵活适配多样化需求。
最终，系统于 2024 年 7 月顺利上线并对外提供服务，目前已接入 563 家纱线工厂，运行状态稳定，各项功能满足客户需求，生产效率提升、数字化管理等核心指标得到客户一致认可。项目实施过程中，我们也遇到了一些挑战：初期部分开发人员对设计模式的理解不够深入，导致部分代码未能完全遵循设计模式的核心思想，出现了 “形式上使用设计模式但未达到解耦效果” 的问题。为解决这一问题，我们采取了两项措施：一是组织设计模式专项培训，结合项目实际场景拆解设计模式的应用逻辑，让开发人员理解 “为何用” 而非 “如何用”；二是在代码评审环节增设 “设计模式应用合规性” 检查项，确保代码符合设计模式的设计初衷。