在开发中，你一定写过这样的代码：ifpay_type=="wechat":...elifpay_type=="alipay":...elifpay_type=="bank":...刚开始还好，但随着业务发展：分支越来越多逻辑越来越复杂修改一个分支可能影响其他逻辑这时候代码就会变得：难维护、难扩展、容易出错。这正是策略模式（Strategy）要解决的问题。一、策略模式解决什么问题？一句话：定义一系列算法（策略），将它们封装起来，并且可以互相替换。关键词：算法封装动态切换避免if...

在很多系统中，会存在这样的情况：对象数量非常多对象之间大量属性是相同的只有少量状态不同如果每个对象都完整创建，就会导致：内存占用巨大对象创建成本高系统性能下降这时候就可以使用享元模式（Flyweight）。一、享元模式解决什么问题？一句话：通过共享对象，减少内存使用。核心思想：把对象中可共享的部分提取出来多个对象共享同一份数据只把不同的部分作为外部状态关键词：对象共享内存优化内部状态外部状态二、一个典型场景：文本编辑器假设一个文档有100万字符。每个字符对象可能包含：字符内容字体字号颜色位置如果每个字符都是完整对象：1000000×字体信息×样式信息大量数据是重复的。例如：字符:"A...

在很多系统中，我们并不会直接访问某个对象，而是通过一个”中间层”来完成访问。例如：访问远程服务（RPC）数据库懒加载权限控制缓存代理日志记录客户端看起来是在访问对象本身，但实际上中间有一层”代理”。这就是代理模式（Proxy）。一、代理模式解决什么问题？一句话：为一个对象提供一个替身（代理），以控制对该对象的访问。关键词：控制访问延迟加载权限控制远程访问代理对象与真实对象实现相同接口，客户端并不知道自己访问的是代理还是原对象。二、一个典型场景：图片懒加载假设系统中需要加载图片，但图片文件很大：加载速度慢占用内存可能根本不会被使用如果直接创建对象：classRealImage:def__init...

在复杂系统中，一个功能往往需要调用多个子系统：数据库缓存消息队列日志系统权限系统如果客户端直接调用这些子系统，就会出现：调用顺序复杂强耦合代码难维护这时就需要一个统一入口。这就是外观模式（Facade）。一、外观模式解决什么问题？一句话：为复杂子系统提供一个统一的简化接口。关键词：简化接口隐藏复杂性解耦客户端与子系统二、一个真实业务场景假设我们有一个电商”下单流程”。一个订单涉及：库存系统支付系统物流系统通知系统如果客户端自己调用：inventory.check(product_id)payment.pay(user_id,amount)logistics.create_order(order...

在开发中，你是否遇到过这样的需求：给函数增加日志给接口增加权限校验给方法增加缓存给对象增加额外功能但你又不想：修改原有类破坏原有逻辑使用大量继承这时候就轮到——装饰器模式。一、装饰器模式解决什么问题？一句话：在不修改原对象结构的情况下，动态地给对象增加额外功能。关键词：动态增强不修改原类不使用继承扩展二、一个不用装饰器的”笨办法”假设有一个通知类：classNotifier:defsend(self,message):print(f"发送消息:{message}")现在要增加”日志功能”。很多人会直接修改：classNotifier:defsend(se...

在业务系统中，有一种结构非常常见：组织架构文件系统菜单系统权限树评论树商品分类它们都有一个共同点：整体和部分具有一致的结构。这正是组合模式要解决的问题。一、组合模式解决什么问题？一句话：将对象组合成树形结构以表示”部分-整体”的层次结构，使客户端对单个对象和组合对象的使用具有一致性。关键词：树结构递归统一接口单个对象和组合对象一致处理二、一个典型场景：公司组织架构假设我们要表示：总公司├──技术部│├──后端组│└──前端组└──财务部如果不用组合模式，可能会这样设计：DepartmentTeamEmployee然后写大量if/else来区分类型。问题是：上层逻辑不得不关心”这是部门还是团队？...

在讲桥接模式之前，先问一个问题：如果一个类有两个变化维度，你会怎么设计？很多人第一反应是——继承。但当继承层级开始”爆炸”时，桥接模式就该登场了。一、桥接模式解决什么问题？一句话：将抽象部分与实现部分分离，使它们可以独立变化。关键词：抽象（Abstraction）实现（Implementation）解耦组合替代继承二、一个典型的继承爆炸问题假设我们要设计一个”消息通知系统”。消息类型有：普通消息紧急消息发送渠道有：邮件短信微信很多人会这样写：classEmailNormalMessage:passclassEmailUrgentMessage:passclassSMSNormalMessage...

一、适配器模式解决什么问题？一句话：接口不兼容，但你又不能改原有代码。现实世界类比：国标插头插不进英标插座需要一个转换头软件世界中：老系统接口不能改第三方库接口格式不一致新旧系统并存这时就需要——适配器（Adapter）。二、定义将一个类的接口转换成客户端期望的另一个接口，使原本由于接口不兼容而不能一起工作的类可以一起工作。核心关键词：接口转换不修改原类让旧代码继续工作三、一个真实业务场景假设你原本系统中定义了统一支付接口：classPayment:defpay(self,amount):pass后来接入一个第三方支付SDK：classThirdPartyPay:defmake_payment...

在前几篇中，我们讨论的都是：如何创建对象如何复制对象如何构建复杂对象而对象池模式关注的是一个更现实的问题：对象创建太贵了，能不能不要频繁创建？这就是ObjectPool（对象池）存在的意义。一、什么是对象池模式？一句话定义：对象池模式通过维护一组可复用对象，避免频繁创建和销毁，从而提升性能。核心思想：预先创建一批对象使用时从池中取出用完后归还池中不重复创建二、什么时候需要对象池？对象池并不是”通用解法”，它只适合以下场景：1.对象创建成本高例如：数据库连接网络连接线程大型文件句柄GPU资源2.对象数量可控对象池通常会限制最大数量，否则会失控。三、最典型案例：数据库连接池想象一个Web服务：de...

在前面的几种创建型模式中（工厂、抽象工厂、建造者），我们解决的核心问题都是：“对象该怎么创建？”而原型模式关注的是另一件事：“对象已经很复杂了，能不能直接复制一个？”这就是Prototype（原型）模式要解决的问题。一、原型模式要解决什么问题？原型模式的核心思想一句话就够了：通过复制已有对象来创建新对象，而不是通过new或构造函数。它适合解决这类场景：对象创建成本很高（初始化复杂、耗时）对象结构复杂，构造参数多需要大量相似对象，只在少量属性上不同希望避免大量重复的初始化逻辑二、一个”很痛苦”的对象创建例子先看一个不使用原型模式的写法。classReport:def__init__(self):...