easy-vibe 设计模式实战指南从创建型到行为型的六大模式与 AI 辅助重构【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe::: tip 导读 本文是 easy-vibe 工程卓越Engineering Excellence专题下的设计模式基础篇面向 AI 原生开发者系统讲解编程世界最实用的六大设计模式Singleton、Factory、Adapter、Decorator、Observer、Strategy。读完本文你将掌握每种模式的适用场景、JavaScript 实现套路能对照问题 → 模式决策表快速选型并学会用大模型辅助识别代码中的重构机会——真正理解哪种模式用在哪种场合而不是死记硬背。 :::0. 全景设计模式的本质与分类为什么你的代码总是能跑但是乱你很可能遇到过这种情况需求一变代码就要大改想复用一段逻辑却发现它和别的代码纠缠在一起。设计模式是前人总结出的代码组织配方帮助你写出灵活、可维护的代码。打个比方学做菜时你既可以每次都从零摸索也可以先学经典菜谱——菜谱不会限制你的创造力而是让你站在前人的肩膀上。设计模式就是编程世界的经典菜谱。设计模式的三大价值共同语言说一句这里用 Observer 模式团队立刻理解你的设计意图沟通成本降到最低经验复用不必掉进别人已经踩过的坑直接复用经过验证的解决方案灵活扩展好的模式让代码面对变更时只需小幅修改而不是推倒重写。三大分类分类解决的问题代表模式创建型Creational如何优雅地创建对象Singleton、Factory结构型Structural如何组织代码结构Adapter、Decorator行为型Behavioral如何管理对象之间的交互Observer、Strategy在 easy-vibe 仓库中本章页面还内嵌了两个交互组件帮助理解这些分类模式目录浏览组件与模式练习场组件详见后文源码分析。1. 创建型模式如何优雅地创建对象创建型模式解决的是如何创建对象的问题让创建过程更灵活、更可控。1.1 Singleton单例模式适用场景全局只需要一个实例例如配置管理器、日志记录器、数据库连接池。class ConfigManager { static instance null static getInstance() { if (!ConfigManager.instance) { ConfigManager.instance new ConfigManager() } return ConfigManager.instance } constructor() { this.config {} } } // 无论调用多少次始终是同一个实例 const a ConfigManager.getInstance() const b ConfigManager.getInstance() console.log(a b) // true实现要点通过static instance持有唯一实例static getInstance()作为全局访问点构造函数直接new会被绕过单例约束生产代码中可考虑将构造逻辑私有化如配合闭包或模块作用域数据库连接池、全局配置这类重复创建代价高、状态需全局共享的对象是最典型的应用场景。源码佐证easy-vibe 仓库的模式目录组件数据中给出了同类示例将instance判断简化为if (!this.instance)的写法并把单例目标对象换成Database数据库连接——可见全局唯一 全局访问点是单例的两个核心要素详见 DesignPatternCatalogDemo.vue 所引用的目录数据en.js。1.2 Factory工厂模式适用场景根据不同的条件创建不同类型的对象调用方无需知道具体的创建细节。function createNotification(type, message) { switch (type) { case email: return { send: () console.log(发送邮件: ${message}) } case sms: return { send: () console.log(发送短信: ${message}) } case push: return { send: () console.log(推送通知: ${message}) } default: throw new Error(未知的通知类型: ${type}) } } // 调用方不关心具体实现 const notification createNotification(email, 你好) notification.send()实现要点工厂把类型判断 对象组装的逻辑集中在一处调用方只面对统一的返回接口这里统一暴露send()新增类型时只需在工厂内增加分支调用方代码零改动工厂模式变体还有简单工厂、工厂方法、抽象工厂难度递增本教程的switch版本属于最易上手的简单工厂足以覆盖大多数前端场景。源码佐证仓库目录数据中的 Factory 示例与上文同构通过switch分支返回EmailNotify、SmsNotify、PushNotify三种通知对象印证了按条件返回不同类型对象、隐藏创建细节的核心思路en.js。2. 结构型模式如何组织代码结构结构型模式解决的是如何组织代码的问题让结构更清晰、组件间的配合更顺畅。2.1 Adapter适配器模式适用场景两个接口不兼容需要一个转换插头。例如旧 API 返回的数据格式与新版组件期望的格式不一致。// 旧 API 返回的格式 const oldApi { getUserInfo: () ({ user_name: 张三, user_age: 25 }) } // 适配器转换为新格式 function adaptUser(oldUser) { return { name: oldUser.user_name, age: oldUser.user_age } } const user adaptUser(oldApi.getUserInfo()) // { name: 张三, age: 25 }实现要点适配器的本质是格式转换层不改动旧接口也不改动新组件的消费逻辑只在中转时做字段映射典型的实战场景对接第三方 API、兼容遗留系统接口、统一多个数据源的返回结构仓库目录数据中的 Adapter 示例采用类封装形式ApiAdapter持有旧接口实例并在fetch()内调用getData()即组合 委托的标准适配思路en.js。2.2 Decorator装饰器模式适用场景不修改原代码的前提下给对象动态添加新功能。就像给手机套上保护壳——手机功能不变但多了防护。// 基础日志函数 function log(message) { console.log(message) } // 装饰添加时间戳 function withTimestamp(fn) { return (message) fn([${new Date().toISOString()}] ${message}) } // 装饰添加日志级别 function withLevel(fn, level) { return (message) fn([${level}] ${message}) } const enhancedLog withTimestamp(withLevel(log, INFO)) enhancedLog(服务启动成功) // [2025-01-15T10:30:00.000Z] [INFO] 服务启动成功实现要点装饰器通过包裹函数逐层增强可任意组合、按需叠加比继承更灵活每次装饰都返回一个新函数原函数log未被改动符合开闭原则对扩展开放、对修改关闭仓库目录数据中的 Decorator 示例展示了通用写法withLogging(fn)包裹任意函数在调用前后打印日志并透传this与参数en.js——这正是函数式装饰器的标准模式。3. 行为型模式如何管理对象之间的交互行为型模式解决的是对象之间如何交互协作的问题让协作更松散、耦合度更低。3.1 Observer观察者模式适用场景一个对象的状态变化后需要自动通知其他多个对象。例如用户下单后需要同时发送邮件、扣减库存、记录日志。class EventEmitter { constructor() { this.listeners {} } on(event, callback) { if (!this.listeners[event]) this.listeners[event] [] this.listeners[event].push(callback) } emit(event, data) { (this.listeners[event] || []).forEach(cb cb(data)) } } const bus new EventEmitter() bus.on(order:created, (order) console.log(发送确认邮件, order.id)) bus.on(order:created, (order) console.log(扣减库存, order.id)) bus.emit(order:created, { id: ORD-001 })实现要点核心是发布-订阅解耦发布者emit不感知订阅者是谁订阅者on不干扰发布者逻辑事件名用字符串命名空间如order:created可避免冲突也便于统一管理前端的事件系统、状态管理、消息推送都是 Observer 的典型应用。源码佐证easy-vibe 的交互练习场组件将 Observer 做成了可操作演示——添加订阅者addSubscriber、发布事件publishEvent并实时记录订阅 / 退订 / 发布日志每次发布会按顺序通知全部订阅者并高亮显示PatternPlaygroundDemo.vue。仓库目录数据中的EventBus示例还展示了(this.listeners[event] || []).push(fn)与?.forEach的现代写法逻辑与上文的EventEmitter完全一致en.js。3.2 Strategy策略模式适用场景同一操作存在多种算法/策略需要在运行时切换。例如不同的排序方式、不同的计价规则。const pricingStrategies { normal: (price) price, vip: (price) price * 0.8, svip: (price) price * 0.6 } function calculatePrice(price, memberLevel) { const strategy pricingStrategies[memberLevel] || pricingStrategies.normal return strategy(price) } calculatePrice(100, vip) // 80 calculatePrice(100, svip) // 60实现要点策略模式把算法封装成可替换的对象/函数客户端通过 key 选择策略未命中时回退到默认策略|| pricingStrategies.normal是实用的防御写法新增策略只需往策略表里加一项不需要改动调用逻辑支付方式、校验规则、促销折扣等行为族可互换的场景都适合用策略模式。源码佐证easy-vibe 的练习场组件为 Strategy 提供了排序场景演示——同一组数据可切换冒泡Bubble、选择Selection、插入Insertion三种排序策略并统计各自的步数与复杂度均标注为 O(n²)直观展示数据不变、算法可换的效果PatternPlaygroundDemo.vue、en.js。4. 如何选择设计模式一张决策表面对实际问题时不要抡起锤子找钉子。先明确你遇到的问题再对照下表选择模式遇到的问题推荐模式核心思想全局只需要一个实例Singleton控制实例数量根据条件创建不同对象Factory封装创建逻辑不兼容的接口需要转换Adapter用转换层包装需要动态添加功能Decorator逐层增强状态变化需要通知多方Observer发布-订阅解耦多种算法需要运行时切换Strategy把算法封装成对象::: tip 核心原则 设计模式不是越多越好。过度设计与毫无设计同样糟糕。只在真正需要灵活性的地方使用模式简单问题就用简单方案解决。记住 KISS 原则Keep It Simple, Stupid保持简单。 :::从源码结构看easy-vibe 的模式目录组件正是按这张分类逻辑实现的点击创建型 / 结构型 / 行为型任一类别卡片即可展开该类别下各模式查看其设计意图intent、适用场景when与代码示例code三个类别的图标与配色也相互区分️ 创建 / 结构 / 行为DesignPatternCatalogDemo.vue。5. AI 辅助用大模型学习与应用设计模式大模型可以帮助你识别代码中适合应用设计模式的场景并给出具体的重构方案。以下是三组可以直接复用的 Prompt。5.1 识别可应用的模式Prompt分析以下代码判断是否存在可以用设计模式改进的机会。 如果存在请说明 1. 当前代码的问题 2. 推荐使用哪种设计模式 3. 重构后的代码示例 4. 为什么该模式适合这个场景 [粘贴你的代码]5.2 用具体场景学习模式Prompt以一个真实场景外卖点餐系统为例演示以下设计模式的应用 - 工厂模式创建不同类型的订单 - 观察者模式订单状态变更通知 - 策略模式不同的配送费计算规则 使用 JavaScript 代码示例。对每个模式先展示不使用模式时的问题 再展示应用模式后的改进。5.3 判断是否过度设计Prompt审查以下代码判断是否存在过度设计的问题。 是否存在不必要的抽象、没用上的设计模式、过早优化 如果存在请根据 KISS 原则提出简化建议。 [粘贴你的代码]::: tip AI 使用建议 让 AI 用你熟悉的业务场景来解释设计模式远比看抽象的 UML 类图更有效。但要记住AI 往往倾向于给出更复杂的方案你需要自行判断这些复杂度是否真的必要——回到第 4 节的决策表与 KISS 原则做最终裁决。 :::6. 总结创建型模式解决如何创建对象的问题让创建过程更灵活Singleton、Factory结构型模式解决如何组织代码的问题让结构更清晰Adapter、Decorator行为型模式解决对象如何交互的问题让协作更松散、耦合更低Observer、Strategy灵活应用根据实际场景选择不要为了用模式而用模式。::: tip 最终思考 设计模式的本质是管理变化。好的设计让容易变化的部分便于修改让稳定的部分保持稳定。写代码时问自己如果需求变了我需要改几个地方——如果答案是很多地方那你可能就需要一个设计模式来帮忙。 :::延伸阅读经典著作GoF四人组的《设计模式可复用面向对象软件的基础》是设计模式的奠基之作现代视角得益于 JavaScript 的语言特性闭包、高阶函数很多模式在 JS 中实现得更简洁本文的 Decorator 函数式写法就是例证实践建议先理解问题再考虑模式不要抡着锤子找钉子进阶学习学习 SOLID 原则它们是设计模式背后的指导思想。仓库延伸本文对应原文档为 design-patterns.md阿拉伯语版完整源码与交互组件位于 DesignPatternCatalogDemo.vue 与 PatternPlaygroundDemo.vue多语言文案数据见 en.js项目基于 VitePress 构建package.json本地可通过npm run dev启动文档站预览交互效果。【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考