随着项目规模的增长，代码的组织方式变得越来越重要。刚开始写一个小功能时，所有的逻辑挤在一个文件里似乎还能应付。但当页面增加到几十个、组件层层嵌套、业务逻辑交错复杂时，代码的可读性和可维护性就会急剧下降。这时候，设计模式提供了一些经过验证的解决方案，帮助我们写出更清晰、更健壮的代码。今天这篇文章，我们就从小程序开发的实际场景出发，聊聊那些真正用得上、也值得掌握的设计模式。
在小程序开发中，有些对象在整个应用中只需要存在一个实例，比如全局的数据管理器、网络请求的配置对象、用户登录态的管理器等。如果每次使用都重新创建，不仅浪费资源，还可能导致数据不一致的问题。
单例模式的核心思想是确保一个类只有一个实例，并提供一个全局访问点来获取这个实例。在小程序中，我们可以利用模块化的特性来实现单例：一个模块导出的是一个对象实例而不是一个类，其他模块引用这个实例时，实际上引用的是同一个对象。
举个例子，用户信息管理模块只应该有一个实例，多个页面通过这个实例来读写用户数据，保证了数据的一致性。请求拦截器也适合用单例模式，所有的网络请求共用一套拦截逻辑，统一处理登录态过期、错误码转换等操作。
页面和组件之间的通信是小程序中常见的需求，但如果直接在组件中调用父页面的方法，或者在页面中操作子组件，就会形成紧密的耦合，后续修改和维护都会变得困难。
观察者模式通过一个事件中心来解耦发送者和接收者。事件发送方不需要知道谁会接收事件，只需要把事件发送出去；事件接收方也不需要知道事件从哪来，只需要监听自己感兴趣的事件。这种模式在小程序中最常见的应用就是跨页面通信。
当用户在一个页面修改了个人信息，另一个页面需要同步更新时，传统的方式可能需要层层传递数据，或者通过全局变量来共享。使用观察者模式，修改信息的页面发布一个“用户信息更新”事件，所有关心这个事件的页面自动响应并刷新界面，发送方和接收方完全不知道对方的存在，耦合度降到了最低。
当创建某个对象的过程比较复杂，或者创建逻辑可能发生变化时，把创建过程封装到一个工厂函数或工厂类中，可以让调用方摆脱创建细节的依赖。
在电商小程序中，不同类型的商品订单创建逻辑各不相同。实物商品需要计算运费，虚拟商品不需要；普通商品正常发货，预售商品有特殊的发货时间逻辑。使用工厂模式，根据商品类型返回不同的订单处理器，创建订单的代码只需要调用工厂获取处理器然后调用统一的方法，具体的创建细节被完全隔离在工厂内部。
策略模式允许在运行时根据不同的情况选择不同的算法或行为。在小程序开发中，最常见的应用场景是表单校验和数据格式化。
一个表单可能包含多个字段，每个字段的校验规则不同，而且校验规则可能随着业务调整而改变。如果把校验逻辑写死在代码中，每次调整都要修改原有函数，容易引入新的问题。使用策略模式，为每种字段类型定义一个校验策略，表单组件只需要根据字段类型选择对应的校验策略执行即可。新增或修改某种字段的校验规则时，只需要调整对应的策略实现，不会影响其他字段的校验逻辑。
当需要给某个组件或函数添加额外的能力，但又不想修改原有的代码时，装饰器模式就派上了用场。它通过包装原有的对象，在保留原有功能的基础上附加新的行为。
比如在数据上报的场景中，我们希望每次用户点击按钮时自动记录埋点数据，但又不想在每个按钮的点击事件中都手动调用埋点方法。通过装饰器模式，我们可以创建一个高阶函数，它接收原有的点击处理函数作为参数，返回一个新的函数，这个新函数在执行原有逻辑之前先执行埋点上报。原有的业务逻辑代码完全不需要改动，埋点功能就被无缝地加了进来。
小程序开发中经常会遇到外部依赖的接口变化，或者需要对接多个不同服务商的情况。适配器模式通过一个中间层来转换接口，让不兼容的接口变得兼容。
比如支付功能，微信支付和支付宝支付的接口参数和调用方式不同，但业务层的下单逻辑不应该关心这些差异。通过适配器模式，我们为不同的支付方式分别实现适配器，业务层统一调用适配器的支付方法，适配器内部完成具体平台的接口转换。当需要切换支付渠道时，只需要更换适配器即可，业务代码几乎不受影响。
学习设计模式不是为了在代码中强行套用，而是在遇到具体问题时能够多几种思路去解决。很多优秀的开源框架和小程序组件库中，都能看到这些模式的应用身影。
掌握设计模式还有一个长远的好处，就是让团队协作中的沟通更加高效。当你和同事说“这里用观察者模式做通信”，对方立刻就能理解你的架构意图，而不需要从头解释你的设计思路。
对于初学者来说，不需要一次性记住所有的模式。先从最常用的几种入手，在项目中遇到合适的场景时尝试应用，慢慢积累经验。设计模式本质上是对软件开发中常见问题的经验总结，理解它们解决问题的思路，比记住模式的名字和结构更为重要。写出能运行的代码只是起点，写出别人能轻松理解和维护的代码，才是工程师真正需要追求的目标。
