[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"site-settings":3,"\u002Farticles\u002Fdesign-pattern-01":26,"\u002Farticles\u002Fdesign-pattern-01\u002Frelated":43,"\u002Farticles\u002Fdesign-pattern-01\u002Fadjacent":69,"\u002Fcategories":82,"render-design-pattern-01":106},{"code":4,"message":5,"data":6},0,"ok",{"author_city":7,"author_years":8,"site_tagline":9,"site_description":10,"skill_one_desc":11,"author_status":12,"skill_two_title":13,"about_hero_image":9,"skill_one_title":14,"icp":15,"author_role":16,"og_default_image":9,"closing_quote_date":17,"toolkit":18,"skill_two_desc":19,"author_bio":9,"site_footer":9,"site_url":20,"author_tagline":21,"weekly_thought":9,"tagline_line_one":22,"author_bio_two":9,"closing_quote":23,"site_name":24,"tagline_line_two":25,"home_hero_image":9},"西安","10","","花开空白 - 个人博客","熟悉Java、Python、Go等后端语言。","努力工作中","前端开发","后端开发","陕ICP备2021009682号-1","开发者","2022年·秋","Java,JavaScript,TypeScript,Python,Go","熟悉Js、Ts语言以及Vue、uniapp等框架。","https:\u002F\u002Firule.cn","很高兴遇见你。","把复杂的事，","把每次一发布，都当成一次和陌生人的握手。","花开空白","写成简单的故事。",{"code":4,"message":5,"data":27},{"id":28,"slug":29,"title":30,"summary":31,"coverUrl":9,"categoryId":32,"status":33,"topFlag":4,"viewCount":34,"likeCount":4,"wordCount":35,"readingMinutes":36,"publishedAt":37,"contentMd":38,"contentHtml":39,"tags":40,"metaTitle":9,"metaDescription":9,"keywords":9,"canonicalUrl":9,"robots":41,"ogImage":9,"faq":42,"aiSummary":42},"2113907939247919106","design-pattern-01","设计模式修炼之路 ① 初识设计模式——先把地图摊开","这是系列的第一篇，没有一行代码：设计模式是什么、模式分哪四大家族、六大原则长什么样。先把地图摊开，路从下一篇开始走。","2113897628365230081",1,4,1903,5,"2026-10-24T16:18:22","\n> 这是系列的第一篇，没有一行代码：设计模式是什么、模式分哪四大家族、六大原则长什么样。先把地图摊开，路从下一篇开始走。\n\n刚写代码那几年，听得最多的一句忠告是\"降低耦合\"。降低耦合降低耦合降低耦合——听了一百遍，落到键盘上还是不知道从哪儿下手。直到某天接手一个三千行的 Service，一个方法里 if-else 套了六层，想加个小功能却牵一发动全身，我才真正明白：耦合不是靠喊的，是靠设计的。设计模式，就是前人把\"怎么设计\"这件事按场景总结出来的一套套可复用的解法。\n\n这个系列是一份修炼记录：从单例开始，创建型、结构型、行为型、J2EE 一路练过去，每个模式配一套能直接编译运行的代码，讲清楚它解决什么问题、有什么代价。这一篇是开篇，只摊地图，不上代码。\n\n## 一、什么是设计模式\n\n一句话版本：**设计模式是针对特定场景、经过反复验证的经典解法**。\n\n拆开是三层意思：\n\n1. **针对特定场景**。每个模式都有它要解决的问题——单例解决\"只该有一份\"，工厂解决\"实例从哪来\"，观察者解决\"一处变化、多方得知\"。脱离问题谈模式，就是屠龙之技。\n2. **经过反复验证**。模式不是哪个大牛拍脑袋的灵感，而是无数项目踩坑踩出来的公约数。1994 年 GoF 四人组的《设计模式：可复用面向对象软件的基础》整理了 23 个，从此成了这个领域的通用语。\n3. **是套路，不是银弹**。用对了是杠杆，用错了是枷锁——不问场景硬套模式，比不用还糟。这个系列会反复念叨一句话：先有问题，再有模式。\n\n学它图什么？往大了说，代码可复用、可扩展、好维护；往小了说，它给团队一套共同语言——一句\"这里用策略模式\"，顶得上十分钟的手舞足蹈。\n\n## 二、四大分类与系列路线图\n\nGoF 的 23 个模式按\"管什么\"分成三族；工程里常用的 J2EE 表现层模式，算第四族。这个系列在 GoF 之外顺带练了过滤器、空对象两个常见\"编外\"模式，再加 8 个 J2EE 模式，一共 33 个：\n\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>分类\u003C\u002Fth>\u003Cth>管什么\u003C\u002Fth>\u003Cth>本系列篇目\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd>创建型（5 种）\u003C\u002Ftd>\u003Ctd>对象怎么\"造\"——造几个、从哪造、怎么造得舒坦\u003C\u002Ftd>\u003Ctd>② 单例、③ 工厂（含抽象工厂）、④ 建造者、⑤ 原型\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>结构型（8 种）\u003C\u002Ftd>\u003Ctd>类和对象怎么\"组装\"——小结构拼成大结构\u003C\u002Ftd>\u003Ctd>⑥ 适配器、⑦ 桥接、⑧ 过滤器、⑨ 组合、⑩ 装饰器、⑪ 外观、⑫ 享元、⑬ 代理\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>行为型（12 种）\u003C\u002Ftd>\u003Ctd>职责怎么\"分\"、消息怎么\"传\"\u003C\u002Ftd>\u003Ctd>⑭ 模板、⑮ 策略、⑯ 观察者、⑰ 责任链、⑱ 命令、⑲ 状态、⑳ 迭代器、㉑ 备忘录、㉒ 中介者、㉓ 空对象、㉔ 访问者、㉕ 解释器\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>J2EE（8 种）\u003C\u002Ftd>\u003Ctd>表现层的老朋友\u003C\u002Ftd>\u003Ctd>㉖ MVC、㉗ 业务代表、㉘ 组合实体、㉙ DAO、㉚ 前端控制器、㉛ 拦截过滤器、㉜ 服务定位器、㉝ 传输对象\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\n\n表里的顺序就是建议的阅读顺序：创建型打底，先把对象的生老病死搞清楚；结构型和行为型经常回头引用前面的套路；J2EE 收常见框架背后的模式。全部走完，㉞ 收官篇用六大原则算总账。\n\n## 三、六大原则速览\n\n模式有 33 个，原则只有六条。打个比方：**模式是判例，原则是法律**——每个模式背后，都是某几条原则的具体化。\n\n先请两条祖训压阵，GoF 那本红皮书开篇立的：**面向接口编程，而不是面向实现；组合优于继承**。六大原则，差不多就是这两条祖训加上开闭原则的展开版：\n\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>原则\u003C\u002Fth>\u003Cth>一句话版本\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd>单一职责\u003C\u002Ftd>\u003Ctd>一个类只因一个原因变——只干一件事\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>开闭原则\u003C\u002Ftd>\u003Ctd>对扩展开放，对修改关闭\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>里氏替换\u003C\u002Ftd>\u003Ctd>子类必须能无痛替换父类，继承不是白拿的\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>依赖倒置\u003C\u002Ftd>\u003Ctd>依赖抽象，不依赖具体实现\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>接口隔离\u003C\u002Ftd>\u003Ctd>接口要小而专，别逼实现方背用不到的方法\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>迪米特法则\u003C\u002Ftd>\u003Ctd>只和直接朋友说话，别跟陌生人套近乎\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\n\n不少教材还会加第七条\"合成复用\"（多用组合、少用继承），凑成七大原则。本系列按六条走——合成复用就当\"组合优于继承\"那条祖训的镜像，在结构型那几篇里它会反复出场。\n\n第一次看，这六行就是六行字，背了就忘，很正常。先混个脸熟就好：后面三十多篇里，它们会一个一个从字里行间站起来——下一篇的单例就会先撞上开闭和单一职责两堵墙，收官篇我们再回头逐条算总账。到那时候，每一行背后都是一路踩过的坑。\n\n## 四、这个系列怎么练\n\n三条姿势建议：\n\n1. **先问\"它解决什么问题\"，再看 UML**。记不住类图不影响使用，看不懂意图等于白学。每篇都尽量从\"不这么写会怎样\"讲起。\n2. **代码要跑**。光看是学不会骑车的。示例代码统一放在 design-pattern 项目里，一个模式一个包，系列里每一篇的输出都来自实际运行，可以直接复现。\n3. **警惕模式上瘾**。两三百行的小工具类硬拆出策略+工厂+观察者，这不叫设计，叫行为艺术。模式是给\"会变化的地方\"上保险的——先判断哪里会变，再决定用不用。\n\n## 写在最后\n\n这一篇没有代码，摊开的是地图：33 个模式四个家族，六条原则两条祖训。\n\n下一篇，从创建型里最简单也最骗人的一个开始——**单例模式**：一个类在整个应用里只允许一个实例，听着像一句话需求，落实起来能折腾出六种写法，一把锁能玩出两层判断。路上见。\n","\u003Cblockquote>\n \u003Cp>这是系列的第一篇，没有一行代码：设计模式是什么、模式分哪四大家族、六大原则长什么样。先把地图摊开，路从下一篇开始走。\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>刚写代码那几年，听得最多的一句忠告是\"降低耦合\"。降低耦合降低耦合降低耦合——听了一百遍，落到键盘上还是不知道从哪儿下手。直到某天接手一个三千行的 Service，一个方法里 if-else 套了六层，想加个小功能却牵一发动全身，我才真正明白：耦合不是靠喊的，是靠设计的。设计模式，就是前人把\"怎么设计\"这件事按场景总结出来的一套套可复用的解法。\u003C\u002Fp>\n\u003Cp>这个系列是一份修炼记录：从单例开始，创建型、结构型、行为型、J2EE 一路练过去，每个模式配一套能直接编译运行的代码，讲清楚它解决什么问题、有什么代价。这一篇是开篇，只摊地图，不上代码。\u003C\u002Fp>\n\u003Ch2>一、什么是设计模式\u003C\u002Fh2>\n\u003Cp>一句话版本：\u003Cstrong>设计模式是针对特定场景、经过反复验证的经典解法\u003C\u002Fstrong>。\u003C\u002Fp>\n\u003Cp>拆开是三层意思：\u003C\u002Fp>\n\u003Col>\n \u003Cli>\u003Cstrong>针对特定场景\u003C\u002Fstrong>。每个模式都有它要解决的问题——单例解决\"只该有一份\"，工厂解决\"实例从哪来\"，观察者解决\"一处变化、多方得知\"。脱离问题谈模式，就是屠龙之技。\u003C\u002Fli>\n \u003Cli>\u003Cstrong>经过反复验证\u003C\u002Fstrong>。模式不是哪个大牛拍脑袋的灵感，而是无数项目踩坑踩出来的公约数。1994 年 GoF 四人组的《设计模式：可复用面向对象软件的基础》整理了 23 个，从此成了这个领域的通用语。\u003C\u002Fli>\n \u003Cli>\u003Cstrong>是套路，不是银弹\u003C\u002Fstrong>。用对了是杠杆，用错了是枷锁——不问场景硬套模式，比不用还糟。这个系列会反复念叨一句话：先有问题，再有模式。\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>学它图什么？往大了说，代码可复用、可扩展、好维护；往小了说，它给团队一套共同语言——一句\"这里用策略模式\"，顶得上十分钟的手舞足蹈。\u003C\u002Fp>\n\u003Ch2>二、四大分类与系列路线图\u003C\u002Fh2>\n\u003Cp>GoF 的 23 个模式按\"管什么\"分成三族；工程里常用的 J2EE 表现层模式，算第四族。这个系列在 GoF 之外顺带练了过滤器、空对象两个常见\"编外\"模式，再加 8 个 J2EE 模式，一共 33 个：\u003C\u002Fp>\n\u003Ctable>\n \u003Cthead>\n  \u003Ctr>\n   \u003Cth>分类\u003C\u002Fth>\n   \u003Cth>管什么\u003C\u002Fth>\n   \u003Cth>本系列篇目\u003C\u002Fth>\n  \u003C\u002Ftr>\n \u003C\u002Fthead>\n \u003Ctbody>\n  \u003Ctr>\n   \u003Ctd>创建型（5 种）\u003C\u002Ftd>\n   \u003Ctd>对象怎么\"造\"——造几个、从哪造、怎么造得舒坦\u003C\u002Ftd>\n   \u003Ctd>② 单例、③ 工厂（含抽象工厂）、④ 建造者、⑤ 原型\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>结构型（8 种）\u003C\u002Ftd>\n   \u003Ctd>类和对象怎么\"组装\"——小结构拼成大结构\u003C\u002Ftd>\n   \u003Ctd>⑥ 适配器、⑦ 桥接、⑧ 过滤器、⑨ 组合、⑩ 装饰器、⑪ 外观、⑫ 享元、⑬ 代理\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>行为型（12 种）\u003C\u002Ftd>\n   \u003Ctd>职责怎么\"分\"、消息怎么\"传\"\u003C\u002Ftd>\n   \u003Ctd>⑭ 模板、⑮ 策略、⑯ 观察者、⑰ 责任链、⑱ 命令、⑲ 状态、⑳ 迭代器、㉑ 备忘录、㉒ 中介者、㉓ 空对象、㉔ 访问者、㉕ 解释器\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>J2EE（8 种）\u003C\u002Ftd>\n   \u003Ctd>表现层的老朋友\u003C\u002Ftd>\n   \u003Ctd>㉖ MVC、㉗ 业务代表、㉘ 组合实体、㉙ DAO、㉚ 前端控制器、㉛ 拦截过滤器、㉜ 服务定位器、㉝ 传输对象\u003C\u002Ftd>\n  \u003C\u002Ftr>\n \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>表里的顺序就是建议的阅读顺序：创建型打底，先把对象的生老病死搞清楚；结构型和行为型经常回头引用前面的套路；J2EE 收常见框架背后的模式。全部走完，㉞ 收官篇用六大原则算总账。\u003C\u002Fp>\n\u003Ch2>三、六大原则速览\u003C\u002Fh2>\n\u003Cp>模式有 33 个，原则只有六条。打个比方：\u003Cstrong>模式是判例，原则是法律\u003C\u002Fstrong>——每个模式背后，都是某几条原则的具体化。\u003C\u002Fp>\n\u003Cp>先请两条祖训压阵，GoF 那本红皮书开篇立的：\u003Cstrong>面向接口编程，而不是面向实现；组合优于继承\u003C\u002Fstrong>。六大原则，差不多就是这两条祖训加上开闭原则的展开版：\u003C\u002Fp>\n\u003Ctable>\n \u003Cthead>\n  \u003Ctr>\n   \u003Cth>原则\u003C\u002Fth>\n   \u003Cth>一句话版本\u003C\u002Fth>\n  \u003C\u002Ftr>\n \u003C\u002Fthead>\n \u003Ctbody>\n  \u003Ctr>\n   \u003Ctd>单一职责\u003C\u002Ftd>\n   \u003Ctd>一个类只因一个原因变——只干一件事\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>开闭原则\u003C\u002Ftd>\n   \u003Ctd>对扩展开放，对修改关闭\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>里氏替换\u003C\u002Ftd>\n   \u003Ctd>子类必须能无痛替换父类，继承不是白拿的\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>依赖倒置\u003C\u002Ftd>\n   \u003Ctd>依赖抽象，不依赖具体实现\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>接口隔离\u003C\u002Ftd>\n   \u003Ctd>接口要小而专，别逼实现方背用不到的方法\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>迪米特法则\u003C\u002Ftd>\n   \u003Ctd>只和直接朋友说话，别跟陌生人套近乎\u003C\u002Ftd>\n  \u003C\u002Ftr>\n \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>不少教材还会加第七条\"合成复用\"（多用组合、少用继承），凑成七大原则。本系列按六条走——合成复用就当\"组合优于继承\"那条祖训的镜像，在结构型那几篇里它会反复出场。\u003C\u002Fp>\n\u003Cp>第一次看，这六行就是六行字，背了就忘，很正常。先混个脸熟就好：后面三十多篇里，它们会一个一个从字里行间站起来——下一篇的单例就会先撞上开闭和单一职责两堵墙，收官篇我们再回头逐条算总账。到那时候，每一行背后都是一路踩过的坑。\u003C\u002Fp>\n\u003Ch2>四、这个系列怎么练\u003C\u002Fh2>\n\u003Cp>三条姿势建议：\u003C\u002Fp>\n\u003Col>\n \u003Cli>\u003Cstrong>先问\"它解决什么问题\"，再看 UML\u003C\u002Fstrong>。记不住类图不影响使用，看不懂意图等于白学。每篇都尽量从\"不这么写会怎样\"讲起。\u003C\u002Fli>\n \u003Cli>\u003Cstrong>代码要跑\u003C\u002Fstrong>。光看是学不会骑车的。示例代码统一放在 design-pattern 项目里，一个模式一个包，系列里每一篇的输出都来自实际运行，可以直接复现。\u003C\u002Fli>\n \u003Cli>\u003Cstrong>警惕模式上瘾\u003C\u002Fstrong>。两三百行的小工具类硬拆出策略+工厂+观察者，这不叫设计，叫行为艺术。模式是给\"会变化的地方\"上保险的——先判断哪里会变，再决定用不用。\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2>写在最后\u003C\u002Fh2>\n\u003Cp>这一篇没有代码，摊开的是地图：33 个模式四个家族，六条原则两条祖训。\u003C\u002Fp>\n\u003Cp>下一篇，从创建型里最简单也最骗人的一个开始——\u003Cstrong>单例模式\u003C\u002Fstrong>：一个类在整个应用里只允许一个实例，听着像一句话需求，落实起来能折腾出六种写法，一把锁能玩出两层判断。路上见。\u003C\u002Fp>",[],"index,follow",null,{"code":4,"message":5,"data":44},[45,53,61],{"id":46,"slug":47,"title":48,"summary":49,"coverUrl":9,"categoryId":42,"status":33,"topFlag":4,"viewCount":33,"likeCount":4,"wordCount":50,"readingMinutes":51,"publishedAt":52},"2113935380699942913","design-pattern-34","设计模式修炼之路 ㉞ 六大原则再回首——殊途同归的总账","全系列收官篇。没有新模式，没有代码——只有一本记了三十二个模式的账。",3601,10,"2026-10-24T18:07:25",{"id":54,"slug":55,"title":56,"summary":57,"coverUrl":9,"categoryId":42,"status":33,"topFlag":4,"viewCount":33,"likeCount":4,"wordCount":58,"readingMinutes":59,"publishedAt":60},"2113930718034792450","design-pattern-02","设计模式修炼之路 ② 单例模式——一个实例，六种写法","一个类在整个应用里只允许存在一个实例——听着是一句话需求，做起来是一路打怪：懒汉式、饿汉式、双重校验锁、静态内部类、枚举，六种写法沿着\"线程安全\"这条主线层层演进。",5238,14,"2026-10-24T17:48:53",{"id":62,"slug":63,"title":64,"summary":65,"coverUrl":9,"categoryId":42,"status":33,"topFlag":4,"viewCount":4,"likeCount":4,"wordCount":66,"readingMinutes":67,"publishedAt":68},"2113931965261418497","design-pattern-15","设计模式修炼之路 ⑮ 策略模式——if-else 的解药","一个分支一个类、工厂加 Map 连选择处都不写 if-else、Spring 自动收集、线程池拒绝策略",7953,20,"2026-10-24T17:53:50",{"code":4,"message":5,"data":70},{"prev":71,"next":81},{"id":72,"slug":73,"title":74,"summary":75,"coverUrl":76,"categoryId":77,"status":33,"topFlag":33,"viewCount":36,"likeCount":4,"wordCount":78,"readingMinutes":79,"publishedAt":80},"2105199707045675010","kugit-smartgit-gitclient","找一个能平替 SmartGit 的轻量 Git 客户端？试试 KuGit","KuGit 是一款仅 6.7 MB 的 Windows Git 桌面客户端，底层直接调用系统 git，行为与命令行完全一致。它支持多仓库分组与同步状态总览、可拖拽停靠的面板布局、提交图谱与搜索、逐词差异高亮、文件历史与 Blame、冲突解决、贮藏\u002F合并\u002F变基中止等日常操作，并提供明暗主题、中英双语界面、凭据与 SSH 密钥管理以及带 Ed25519 签名校验的自动更新。文章逐项演示了各功能，并客观对比其与 SmartGit 的差异：日常场景下 KuGit 更轻更快，但暂无 macOS\u002FLinux 版本，也缺少交互式变基与 PR 集成，适合作为 Windows 上的日常主力 Git 工具。","https:\u002F\u002Firule.cn\u002Fku-blog\u002Fposts\u002F2026\u002F09\u002F30\u002Ff33ea38ad6b8479c8535d516645f05de.webp","2105200093764698113",2776,7,"2026-09-30T17:48:03",{"id":54,"slug":55,"title":56,"summary":57,"coverUrl":9,"categoryId":42,"status":33,"topFlag":4,"viewCount":33,"likeCount":4,"wordCount":58,"readingMinutes":59,"publishedAt":60},{"code":4,"message":5,"data":83},[84,90,95,101],{"id":85,"name":86,"slug":87,"description":88,"sortOrder":4,"articleCount":89},"1946000000000000001","antlr4","tech","编程与技术笔记","13",{"id":32,"name":91,"slug":92,"description":93,"sortOrder":4,"articleCount":94},"设计模式","design-pattern","设计模式系列","1",{"id":96,"name":97,"slug":98,"description":99,"sortOrder":33,"articleCount":100},"1946000000000000002","随笔","essay","生活与思考","0",{"id":77,"name":102,"slug":103,"description":104,"sortOrder":105,"articleCount":94},"工具","tools","好用的工具推荐",2,{"html":107,"toc":108},"\u003Cblockquote>\n \u003Cp>这是系列的第一篇，没有一行代码：设计模式是什么、模式分哪四大家族、六大原则长什么样。先把地图摊开，路从下一篇开始走。\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>刚写代码那几年，听得最多的一句忠告是\"降低耦合\"。降低耦合降低耦合降低耦合——听了一百遍，落到键盘上还是不知道从哪儿下手。直到某天接手一个三千行的 Service，一个方法里 if-else 套了六层，想加个小功能却牵一发动全身，我才真正明白：耦合不是靠喊的，是靠设计的。设计模式，就是前人把\"怎么设计\"这件事按场景总结出来的一套套可复用的解法。\u003C\u002Fp>\n\u003Cp>这个系列是一份修炼记录：从单例开始，创建型、结构型、行为型、J2EE 一路练过去，每个模式配一套能直接编译运行的代码，讲清楚它解决什么问题、有什么代价。这一篇是开篇，只摊地图，不上代码。\u003C\u002Fp>\n\u003Ch2 id=\"toc-1\">一、什么是设计模式\u003C\u002Fh2>\n\u003Cp>一句话版本：\u003Cstrong>设计模式是针对特定场景、经过反复验证的经典解法\u003C\u002Fstrong>。\u003C\u002Fp>\n\u003Cp>拆开是三层意思：\u003C\u002Fp>\n\u003Col>\n \u003Cli>\u003Cstrong>针对特定场景\u003C\u002Fstrong>。每个模式都有它要解决的问题——单例解决\"只该有一份\"，工厂解决\"实例从哪来\"，观察者解决\"一处变化、多方得知\"。脱离问题谈模式，就是屠龙之技。\u003C\u002Fli>\n \u003Cli>\u003Cstrong>经过反复验证\u003C\u002Fstrong>。模式不是哪个大牛拍脑袋的灵感，而是无数项目踩坑踩出来的公约数。1994 年 GoF 四人组的《设计模式：可复用面向对象软件的基础》整理了 23 个，从此成了这个领域的通用语。\u003C\u002Fli>\n \u003Cli>\u003Cstrong>是套路，不是银弹\u003C\u002Fstrong>。用对了是杠杆，用错了是枷锁——不问场景硬套模式，比不用还糟。这个系列会反复念叨一句话：先有问题，再有模式。\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>学它图什么？往大了说，代码可复用、可扩展、好维护；往小了说，它给团队一套共同语言——一句\"这里用策略模式\"，顶得上十分钟的手舞足蹈。\u003C\u002Fp>\n\u003Ch2 id=\"toc-2\">二、四大分类与系列路线图\u003C\u002Fh2>\n\u003Cp>GoF 的 23 个模式按\"管什么\"分成三族；工程里常用的 J2EE 表现层模式，算第四族。这个系列在 GoF 之外顺带练了过滤器、空对象两个常见\"编外\"模式，再加 8 个 J2EE 模式，一共 33 个：\u003C\u002Fp>\n\u003Ctable>\n \u003Cthead>\n  \u003Ctr>\n   \u003Cth>分类\u003C\u002Fth>\n   \u003Cth>管什么\u003C\u002Fth>\n   \u003Cth>本系列篇目\u003C\u002Fth>\n  \u003C\u002Ftr>\n \u003C\u002Fthead>\n \u003Ctbody>\n  \u003Ctr>\n   \u003Ctd>创建型（5 种）\u003C\u002Ftd>\n   \u003Ctd>对象怎么\"造\"——造几个、从哪造、怎么造得舒坦\u003C\u002Ftd>\n   \u003Ctd>② 单例、③ 工厂（含抽象工厂）、④ 建造者、⑤ 原型\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>结构型（8 种）\u003C\u002Ftd>\n   \u003Ctd>类和对象怎么\"组装\"——小结构拼成大结构\u003C\u002Ftd>\n   \u003Ctd>⑥ 适配器、⑦ 桥接、⑧ 过滤器、⑨ 组合、⑩ 装饰器、⑪ 外观、⑫ 享元、⑬ 代理\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>行为型（12 种）\u003C\u002Ftd>\n   \u003Ctd>职责怎么\"分\"、消息怎么\"传\"\u003C\u002Ftd>\n   \u003Ctd>⑭ 模板、⑮ 策略、⑯ 观察者、⑰ 责任链、⑱ 命令、⑲ 状态、⑳ 迭代器、㉑ 备忘录、㉒ 中介者、㉓ 空对象、㉔ 访问者、㉕ 解释器\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>J2EE（8 种）\u003C\u002Ftd>\n   \u003Ctd>表现层的老朋友\u003C\u002Ftd>\n   \u003Ctd>㉖ MVC、㉗ 业务代表、㉘ 组合实体、㉙ DAO、㉚ 前端控制器、㉛ 拦截过滤器、㉜ 服务定位器、㉝ 传输对象\u003C\u002Ftd>\n  \u003C\u002Ftr>\n \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>表里的顺序就是建议的阅读顺序：创建型打底，先把对象的生老病死搞清楚；结构型和行为型经常回头引用前面的套路；J2EE 收常见框架背后的模式。全部走完，㉞ 收官篇用六大原则算总账。\u003C\u002Fp>\n\u003Ch2 id=\"toc-3\">三、六大原则速览\u003C\u002Fh2>\n\u003Cp>模式有 33 个，原则只有六条。打个比方：\u003Cstrong>模式是判例，原则是法律\u003C\u002Fstrong>——每个模式背后，都是某几条原则的具体化。\u003C\u002Fp>\n\u003Cp>先请两条祖训压阵，GoF 那本红皮书开篇立的：\u003Cstrong>面向接口编程，而不是面向实现；组合优于继承\u003C\u002Fstrong>。六大原则，差不多就是这两条祖训加上开闭原则的展开版：\u003C\u002Fp>\n\u003Ctable>\n \u003Cthead>\n  \u003Ctr>\n   \u003Cth>原则\u003C\u002Fth>\n   \u003Cth>一句话版本\u003C\u002Fth>\n  \u003C\u002Ftr>\n \u003C\u002Fthead>\n \u003Ctbody>\n  \u003Ctr>\n   \u003Ctd>单一职责\u003C\u002Ftd>\n   \u003Ctd>一个类只因一个原因变——只干一件事\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>开闭原则\u003C\u002Ftd>\n   \u003Ctd>对扩展开放，对修改关闭\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>里氏替换\u003C\u002Ftd>\n   \u003Ctd>子类必须能无痛替换父类，继承不是白拿的\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>依赖倒置\u003C\u002Ftd>\n   \u003Ctd>依赖抽象，不依赖具体实现\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>接口隔离\u003C\u002Ftd>\n   \u003Ctd>接口要小而专，别逼实现方背用不到的方法\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>迪米特法则\u003C\u002Ftd>\n   \u003Ctd>只和直接朋友说话，别跟陌生人套近乎\u003C\u002Ftd>\n  \u003C\u002Ftr>\n \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>不少教材还会加第七条\"合成复用\"（多用组合、少用继承），凑成七大原则。本系列按六条走——合成复用就当\"组合优于继承\"那条祖训的镜像，在结构型那几篇里它会反复出场。\u003C\u002Fp>\n\u003Cp>第一次看，这六行就是六行字，背了就忘，很正常。先混个脸熟就好：后面三十多篇里，它们会一个一个从字里行间站起来——下一篇的单例就会先撞上开闭和单一职责两堵墙，收官篇我们再回头逐条算总账。到那时候，每一行背后都是一路踩过的坑。\u003C\u002Fp>\n\u003Ch2 id=\"toc-4\">四、这个系列怎么练\u003C\u002Fh2>\n\u003Cp>三条姿势建议：\u003C\u002Fp>\n\u003Col>\n \u003Cli>\u003Cstrong>先问\"它解决什么问题\"，再看 UML\u003C\u002Fstrong>。记不住类图不影响使用，看不懂意图等于白学。每篇都尽量从\"不这么写会怎样\"讲起。\u003C\u002Fli>\n \u003Cli>\u003Cstrong>代码要跑\u003C\u002Fstrong>。光看是学不会骑车的。示例代码统一放在 design-pattern 项目里，一个模式一个包，系列里每一篇的输出都来自实际运行，可以直接复现。\u003C\u002Fli>\n \u003Cli>\u003Cstrong>警惕模式上瘾\u003C\u002Fstrong>。两三百行的小工具类硬拆出策略+工厂+观察者，这不叫设计，叫行为艺术。模式是给\"会变化的地方\"上保险的——先判断哪里会变，再决定用不用。\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2 id=\"toc-5\">写在最后\u003C\u002Fh2>\n\u003Cp>这一篇没有代码，摊开的是地图：33 个模式四个家族，六条原则两条祖训。\u003C\u002Fp>\n\u003Cp>下一篇，从创建型里最简单也最骗人的一个开始——\u003Cstrong>单例模式\u003C\u002Fstrong>：一个类在整个应用里只允许一个实例，听着像一句话需求，落实起来能折腾出六种写法，一把锁能玩出两层判断。路上见。\u003C\u002Fp>",[109,112,115,118,121],{"id":110,"text":111,"level":105},"toc-1","一、什么是设计模式",{"id":113,"text":114,"level":105},"toc-2","二、四大分类与系列路线图",{"id":116,"text":117,"level":105},"toc-3","三、六大原则速览",{"id":119,"text":120,"level":105},"toc-4","四、这个系列怎么练",{"id":122,"text":123,"level":105},"toc-5","写在最后"]