3、设计模式基础：设计模式概念、GoF分类（创建型、结构型、行为型）、RPA中为何需要设计模式
说实话，我刚开始带RPA团队那会儿，最头疼的不是流程跑不通，而是代码写得「太随意」。
每个人都有自己的写法，今天张三写个循环，明天李四改个判断，后天流程一崩，谁都不知道问题出在哪。
后来我意识到，这不是技术问题，是思维问题。我们需要一套「通用语言」和「标准解法」——这就是设计模式。
3.1 设计模式到底是什么？
设计模式，说白了就是「前人踩过的坑，总结出来的最佳实践」。
它不是代码，不是框架，而是一种解决问题的思路。就像你写RPA流程时，遇到「等待元素出现」这种场景，你可能会用Wait For Element，但更优雅的做法是封装一个「带超时和重试的等待方法」——这就是模式。
核心定义：设计模式是针对特定场景下、可复用的解决方案模板。
它有三个关键点：
- 场景驱动：不是所有地方都需要模式，只有「反复出现的问题」才值得抽象
- 可复用：同一个模式可以在不同流程、不同项目中反复使用
- 经验沉淀：是无数开发者用时间和教训换来的「避坑指南」
我个人习惯把设计模式比作「乐高积木的说明书」。积木块本身（代码）谁都会拼，但怎么搭出稳固的结构，就需要看说明书（设计模式）。
3.2 GoF 23种设计模式分类
说到设计模式，绕不开那本经典的《设计模式：可复用面向对象软件的基础》。四位作者（GoF）总结了23种模式，分成三大类。
嗯，这里要注意，别被23这个数字吓到。实际工作中常用的也就七八种。我当年背得滚瓜烂熟，结果发现RPA里真正高频使用的，其实就那几个。
| 分类 | 核心思想 | 典型模式 | RPA应用场景 |
|---|---|---|---|
| 创建型 | 解决「对象怎么创建」的问题 | 单例、工厂、建造者 | 数据库连接、配置管理、对象池 |
| 结构型 | 解决「类和对象怎么组合」的问题 | 适配器、装饰器、代理 | 系统对接、功能增强、权限控制 |
| 行为型 | 解决「对象之间怎么交互」的问题 | 策略、模板方法、观察者 | 流程分支、异常处理、事件通知 |
3.2.1 创建型模式：管好你的对象
创建型模式关注的是「如何优雅地创建对象」。你想想看，在RPA里，我们经常需要创建各种实例——浏览器对象、数据库连接、Excel应用实例。如果每次都用new，代码会变得很散乱。
单例模式是我在RPA项目里用得最多的。比如全局的日志记录器、配置管理器，整个流程只需要一个实例。我曾经见过一个项目，每个子流程都new一个日志对象，结果日志文件被反复打开关闭，性能直接崩了。
工厂模式也很实用。比如你的流程需要对接不同系统（SAP、Oracle、Web），每个系统的登录方式不同。用工厂模式封装一下，调用方只需要传一个参数，就能拿到对应的登录处理器。
我的经验：在RPA中，创建型模式最适合用来管理「资源密集型对象」。比如浏览器实例、数据库连接池。用单例模式确保全局只有一个，能大幅减少资源消耗。
3.2.2 结构型模式：搭好你的架子
结构型模式解决的是「怎么把不同的东西组合在一起」。RPA开发中，最头疼的就是系统集成——老系统、新系统、第三方API，接口千奇百怪。
适配器模式就是干这个的。我记得有一次对接一个遗留的CS架构系统，它只提供COM接口，而我们的RPA框架只支持REST API。怎么办？写一个适配器，把COM调用包装成REST接口。这样上层代码完全不用改，底层适配器搞定一切。
装饰器模式在RPA里也很有用。比如你有一个基础的「数据抓取」功能，现在想加上「日志记录」「重试机制」「性能监控」。用装饰器模式，一层层包装上去，既保持了核心功能的纯净，又灵活扩展了能力。
避坑指南：我曾经在项目里过度使用装饰器，给一个简单的「点击按钮」功能套了五层装饰器（日志、重试、截图、性能、异常通知）。结果调试时根本分不清是哪一层出了问题。记住：装饰器不要超过三层，否则维护成本会指数级上升。
3.2.3 行为型模式：理清你的交互
行为型模式关注的是「对象之间怎么协作」。RPA流程本质上就是一系列对象的交互——机器人、业务系统、数据库、消息队列。交互一多，就容易乱。
策略模式是我在RPA里最推荐的行为型模式。比如一个「数据校验」流程，不同客户要求不同：有的要校验格式，有的要校验业务逻辑，有的要校验完整性。用策略模式，把每种校验算法封装成独立的策略，运行时动态选择。这样新增一种校验规则，完全不用改原有代码。
模板方法模式也很适合RPA。你想想看，大多数RPA流程都有固定的步骤：登录→导航→操作→验证→退出。把这些固定步骤抽象成模板，子流程只需要实现具体的操作逻辑。这样既保证了流程的一致性，又提高了复用性。
举个例子：我们团队开发了20多个财务流程，每个流程都遵循「登录→查询→处理→归档→退出」的模板。后来业务部门要求增加一个「操作前截图」的步骤，我只需要在模板里加一行代码，所有流程自动生效。这就是模板方法模式的力量。
3.3 RPA中为何需要设计模式？
你可能会问：RPA不就是拖拖拽拽、写点脚本吗？至于用设计模式这么「重」的东西吗？
说实话，我以前也这么想。直到我接手了一个「祖传」的RPA项目——3000多行代码挤在一个脚本里，没有函数，没有类，全是if-else和循环嵌套。改一个bug要花三天，因为根本不知道改了这里会不会影响那里。
RPA需要设计模式，原因有三：
- 可维护性：RPA流程的生命周期往往比想象中长。一个流程上线后，可能要维护3-5年。没有设计模式，后期维护就是噩梦。
- 可扩展性：业务需求变化快。今天对接A系统，明天对接B系统。用设计模式封装好变化点，新增需求时只需要「插拔」对应的模块，而不是重写整个流程。
- 团队协作：RPA开发往往不是一个人单干。设计模式提供了一套「通用词汇」——你说「这里用策略模式」，大家都懂；你说「这里写个if-else判断」，每个人理解都不一样。
我的建议：不要为了用模式而用模式。设计模式是工具，不是目的。如果一个简单的if-else就能解决问题，那就别硬套策略模式。记住：简单性 > 优雅性。在RPA里，可读性和可维护性永远排在第一位。
最后说一句：设计模式不是银弹。它不能解决所有问题，但能帮你建立一种「结构化思考」的习惯。当你开始思考「这个场景适合用什么模式」时，恭喜你，你已经从「码农」进阶到「架构师」了。