Janus-Pro-7B 软件设计模式解析结合实例讲解23种经典模式1. 为什么设计模式值得你花时间每次看到别人写的代码清晰又灵活自己写的却像一团乱麻是不是有点头疼或者接手一个老项目光是理清各个模块怎么调用的就花了大半天。这些问题其实很多都能通过设计模式来解决。设计模式不是什么高深莫测的魔法它就是前辈们在软件开发中针对一些反复出现的问题总结出来的最佳解决方案模板。就像盖房子有标准的结构图纸一样设计模式就是软件设计的“图纸”。学会它们你就能写出更容易理解、更容易维护、也更容易扩展的代码。今天我们就借助 Janus-Pro-7B 这个擅长整合与讲解复杂知识的大模型来系统性地过一遍经典的 GoF 23 种设计模式。我们不搞枯燥的理论堆砌而是针对每一种模式用最直白的话说清楚它想干什么、什么时候用、怎么用代码实现以及用了之后有什么好处和要注意什么。无论你是想巩固基础的开发者还是在准备技术面试这篇文章都能给你带来实实在在的帮助。2. 设计模式快速入门核心思想与分类在深入每一个模式之前我们先花几分钟建立整体认知。理解设计模式的核心思想和分类能让你在后面学习具体模式时思路更清晰。2.1 设计模式到底在解决什么问题简单说设计模式主要为了解决软件设计的“弹性”问题。比如变化点隔离当需求经常变化时如何让修改只发生在一个地方而不是牵一发而动全身对象创建如何创建对象才能更灵活不依赖具体的类对象结构如何将多个对象组合成更大的结构并且这个结构好用又灵活对象行为多个对象之间如何通信和协作才能让职责清晰、耦合度低GoF 的 23 种经典模式就是围绕这些核心问题展开的。2.2 三大类模式创建、结构、行为为了便于理解和记忆这 23 种模式被分成了三大类类别核心关注点包含的模式举例创建型模式对象的创建过程。将对象的创建与使用分离使系统更灵活。工厂方法、抽象工厂、建造者、原型、单例结构型模式类或对象的组合方式。描述如何将类或对象组合成更大、更复杂的结构。适配器、桥接、组合、装饰器、外观、享元、代理行为型模式对象间的职责分配与通信。关注对象之间如何交互、分配职责。观察者、策略、模板方法、迭代器、责任链、命令、状态等接下来我们就从每一类中挑选几个最常用、面试中也最常被问到的模式结合 Janus-Pro-7B 梳理的清晰脉络和实例带你逐个击破。3. 创建型模式精讲让对象诞生更优雅创建型模式管的是“生孩子”的事。它的目标是把对象的创建过程封装起来让系统不依赖于对象是如何创建、组合和表示的。3.1 工厂方法模式决定生什么意图定义一个用于创建对象的接口但让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。生活类比你想喝咖啡去了一家咖啡店抽象工厂。你告诉店员“我要一杯拿铁”店员具体工厂就去用咖啡机具体产品给你做。你不需要关心咖啡机是什么牌子、怎么操作。适用场景当一个类不知道它所需要的对象的类时。当你希望为创建对象提供更高的灵活性时。当你想将产品的创建过程与使用过程解耦时。代码示例Pythonfrom abc import ABC, abstractmethod # 产品接口 class Button(ABC): abstractmethod def render(self): pass # 具体产品 class WindowsButton(Button): def render(self): return “渲染一个Windows风格的按钮” class HTMLButton(Button): def render(self): return “渲染一个HTML按钮” # 创建者工厂接口 class Dialog(ABC): abstractmethod def create_button(self) - Button: pass def render_window(self): # 调用工厂方法创建一个产品对象 button self.create_button() result button.render() return result # 具体创建者 class WindowsDialog(Dialog): def create_button(self) - Button: return WindowsButton() class WebDialog(Dialog): def create_button(self) - Button: return HTMLButton() # 使用 if __name__ “__main__”: config “Windows” # 可以从配置读取 dialog WindowsDialog() if config “Windows” else WebDialog() print(dialog.render_window()) # 输出渲染一个Windows风格的按钮优缺点分析优点符合“开闭原则”新增产品时只需增加新的工厂类无需修改现有代码。创建逻辑清晰用户只关心接口。缺点每增加一个产品就需要增加一个具体工厂类当产品种类非常多时会导致类的数量爆炸式增长。3.2 单例模式独一无二的存在意图保证一个类仅有一个实例并提供一个访问它的全局访问点。生活类比一个国家只能有一个总统正常情况下。无论谁需要总统办事都去找这同一个人。适用场景需要控制资源如数据库连接池、线程池、日志对象、应用配置。需要全局状态管理如缓存。需要频繁创建和销毁的对象但创建开销大。代码示例Javapublic class Singleton { // 静态变量持有唯一实例 private static volatile Singleton instance; // 私有构造器防止外部new private Singleton() { // 初始化代码 } // 全局访问点双重检查锁定线程安全 public static Singleton getInstance() { if (instance null) { // 第一次检查 synchronized (Singleton.class) { if (instance null) { // 第二次检查 instance new Singleton(); } } } return instance; } // 业务方法 public void doSomething() { System.out.println(“单例对象在工作...”); } } // 使用 public class Client { public static void main(String[] args) { Singleton s1 Singleton.getInstance(); Singleton s2 Singleton.getInstance(); System.out.println(s1 s2); // 输出true是同一个对象 } }优缺点分析优点严格控制了实例数量节约系统资源。提供了对唯一实例的受控访问。缺点违反了“单一职责原则”既承担了业务职责又管理了自己的生命周期。在多线程环境下需要特殊处理如双重检查锁。过度使用会导致代码耦合度高不利于单元测试因为全局状态。4. 结构型模式精讲搭建灵活的程序骨架结构型模式关心的是如何组合类和对象以获得更大的结构。它主要处理类或对象的组合形成更复杂、功能更强的结构。4.1 适配器模式让不兼容的接口一起工作意图将一个类的接口转换成客户期望的另一个接口。适配器让那些由于接口不兼容而不能一起工作的类可以一起工作。生活类比你从国外带回来的三脚插头电器被适配者在国内的两脚插座目标接口上没法用。一个转换插头适配器解决了这个问题。适用场景想使用一个已经存在的类但其接口不符合你的需求。想创建一个可以复用的类该类可以与其他不相关的类或不可预见的类协同工作。需要使用几个现有的子类但是通过继承每个子类来适配它们的接口又不现实。代码示例Python# 目标接口客户期望的 class LightningPort: def charge_with_lightning(self): return “使用Lightning接口充电” # 被适配者已有的但不兼容的 class USBCCable: def charge_with_usbc(self): return “使用USB-C接口充电” # 适配器 class USBCToLightningAdapter(LightningPort): def __init__(self, usbc_cable: USBCCable): self._usbc_cable usbc_cable def charge_with_lightning(self): # 调用被适配者的方法但对外表现为Lightning接口 return f“适配器转换中... {self._usbc_cable.charge_with_usbc()}” # 客户端代码 class IPhone: def charge(self, cable: LightningPort): print(cable.charge_with_lightning()) # 使用 if __name__ “__main__”: phone IPhone() usbc_cable USBCCable() adapter USBCToLightningAdapter(usbc_cable) phone.charge(adapter) # 输出适配器转换中... 使用USB-C接口充电优缺点分析优点提高了类的复用性让两个无关的类一起运行。增加了类的透明度对客户端是透明的。缺点过多使用适配器会让系统变得凌乱。比如明明看到调用的是 A 接口内部却被适配成了 B 接口增加了代码的复杂度。4.2 装饰器模式动态添加新功能意图动态地给一个对象添加一些额外的职责。就增加功能来说装饰器模式比生成子类更为灵活。生活类比一件普通的T恤具体组件。你可以给它套一件印花装饰器A再套一件荧光条装饰器B。每加一件T恤就有了新的“功能”但T恤本身没变。适用场景需要在不影响其他对象的情况下以动态、透明的方式给单个对象添加职责。当不能采用继承的方式扩展功能时例如final类或需要大量子类的情况。代码示例Java// 组件接口 interface Coffee { String getDescription(); double getCost(); } // 具体组件 class SimpleCoffee implements Coffee { Override public String getDescription() { return “普通咖啡”; } Override public double getCost() { return 5.0; } } // 装饰器抽象类 abstract class CoffeeDecorator implements Coffee { protected Coffee decoratedCoffee; public CoffeeDecorator(Coffee coffee) { this.decoratedCoffee coffee; } public String getDescription() { return decoratedCoffee.getDescription(); } public double getCost() { return decoratedCoffee.getCost(); } } // 具体装饰器A加牛奶 class WithMilk extends CoffeeDecorator { public WithMilk(Coffee coffee) { super(coffee); } Override public String getDescription() { return super.getDescription() “, 加牛奶”; } Override public double getCost() { return super.getCost() 2.0; } } // 具体装饰器B加糖 class WithSugar extends CoffeeDecorator { public WithSugar(Coffee coffee) { super(coffee); } Override public String getDescription() { return super.getDescription() “, 加糖”; } Override public double getCost() { return super.getCost() 1.0; } } // 使用 public class DecoratorDemo { public static void main(String[] args) { Coffee myCoffee new SimpleCoffee(); System.out.println(myCoffee.getDescription() “ ” myCoffee.getCost()); myCoffee new WithMilk(myCoffee); // 装饰牛奶 System.out.println(myCoffee.getDescription() “ ” myCoffee.getCost()); myCoffee new WithSugar(myCoffee); // 再装饰糖 System.out.println(myCoffee.getDescription() “ ” myCoffee.getCost()); // 输出 // 普通咖啡 5.0 // 普通咖啡, 加牛奶 7.0 // 普通咖啡, 加牛奶, 加糖 8.0 } }优缺点分析优点比继承更灵活可以在运行时动态添加或撤销功能。避免了使用继承导致子类膨胀的问题。符合“开闭原则”。缺点会产生许多小对象装饰器对象增加系统复杂度。排错困难因为装饰是层层包裹的。5. 行为型模式精讲定义对象间的互动之道行为型模式主要关注对象之间的职责分配和通信。它们不仅描述对象或类的模式还描述它们之间的通信模式。5.1 观察者模式建立一对多的依赖意图定义对象间的一种一对多的依赖关系当一个对象的状态发生改变时所有依赖于它的对象都得到通知并被自动更新。生活类比微信公众号被观察者和订阅用户观察者。公众号一发文所有订阅者都能收到推送。适用场景当一个对象的改变需要同时改变其他对象而不知道具体有多少对象有待改变时。当一个对象必须通知其他对象但又不能假定这些对象是谁时即解耦。代码示例Pythonfrom abc import ABC, abstractmethod # 观察者接口 class Observer(ABC): abstractmethod def update(self, message: str): pass # 被观察者主题接口 class Subject(ABC): def __init__(self): self._observers [] def attach(self, observer: Observer): if observer not in self._observers: self._observers.append(observer) def detach(self, observer: Observer): self._observers.remove(observer) def notify(self, message: str): for observer in self._observers: observer.update(message) # 具体被观察者气象站 class WeatherStation(Subject): def __init__(self): super().__init__() self._temperature 0 def set_temperature(self, temp: int): self._temperature temp print(f“气象站温度更新为 {temp}°C”) self.notify(f“当前温度{temp}°C”) # 具体观察者A手机显示 class PhoneDisplay(Observer): def update(self, message: str): print(f“手机显示[天气更新] {message}”) # 具体观察者B户外大屏 class OutdoorDisplay(Observer): def update(self, message: str): print(f“户外大屏**{message}**”) # 使用 if __name__ “__main__”: station WeatherStation() phone PhoneDisplay() outdoor_screen OutdoorDisplay() station.attach(phone) station.attach(outdoor_screen) station.set_temperature(25) # 输出 # 气象站温度更新为 25°C # 手机显示[天气更新] 当前温度25°C # 户外大屏**当前温度25°C** station.detach(phone) station.set_temperature(30) # 输出 # 气象站温度更新为 30°C # 户外大屏**当前温度30°C**优缺点分析优点实现了观察者和被观察者之间的抽象耦合支持广播通信。符合“开闭原则”增加新的观察者很容易。缺点如果观察者很多通知所有观察者会花费较多时间。如果观察者和被观察者之间有循环依赖可能导致系统崩溃。观察者无法知道被观察对象是如何发生变化的。5.2 策略模式自由切换算法意图定义一系列算法将每个算法封装起来并使它们可以互相替换。策略模式让算法的变化独立于使用算法的客户。生活类比出行导航。你可以选择不同的策略最快路线、最短路线、避开收费。导航App上下文根据你选择的策略调用不同的算法来计算路线。适用场景一个系统有许多类它们之间的区别仅在于行为不同。需要动态地在多种算法中选择一种。不希望客户端知道复杂的、与算法相关的数据结构。代码示例Java// 策略接口 interface PaymentStrategy { void pay(int amount); } // 具体策略A信用卡支付 class CreditCardPayment implements PaymentStrategy { private String cardNumber; public CreditCardPayment(String cardNumber) { this.cardNumber cardNumber; } Override public void pay(int amount) { System.out.println(“使用信用卡 ” cardNumber “ 支付 ” amount “ 元”); } } // 具体策略B支付宝支付 class AlipayPayment implements PaymentStrategy { private String account; public AlipayPayment(String account) { this.account account; } Override public void pay(int amount) { System.out.println(“使用支付宝账户 ” account “ 支付 ” amount “ 元”); } } // 上下文购物车 class ShoppingCart { private PaymentStrategy paymentStrategy; public void setPaymentStrategy(PaymentStrategy strategy) { this.paymentStrategy strategy; } public void checkout(int amount) { if (paymentStrategy null) { System.out.println(“请先选择支付方式”); return; } paymentStrategy.pay(amount); } } // 使用 public class StrategyDemo { public static void main(String[] args) { ShoppingCart cart new ShoppingCart(); cart.setPaymentStrategy(new CreditCardPayment(“1234-5678-9012-3456”)); cart.checkout(100); // 输出使用信用卡 1234-5678-9012-3456 支付 100 元 cart.setPaymentStrategy(new AlipayPayment(“userexample.com”)); cart.checkout(200); // 输出使用支付宝账户 userexample.com 支付 200 元 } }优缺点分析优点算法可以自由切换避免了多重条件判断。扩展性好增加新策略很容易。符合“开闭原则”。缺点客户端必须知道所有的策略类并自行决定使用哪一个。策略类会增多增加了系统的对象数量。6. 总结与学习建议一口气看了这么多模式可能有点信息过载。别担心设计模式不是用来死记硬背的而是要在实践中慢慢体会和运用的。回顾一下我们从创建型模式学到了如何优雅地“造对象”从结构型模式学到了如何灵活地“搭积木”从行为型模式学到了如何高效地“搞协作”。学习设计模式最关键的一步不是记住 UML 图而是理解每个模式背后的意图和它要解决的问题。当你遇到代码中“感觉别扭”、“难以修改”、“重复劳动”的地方时不妨想想是不是可以用某个模式来重构。一开始可能会觉得生搬硬套用多了就会越来越顺手。对于准备面试的朋友理解这几种常用模式单例、工厂、观察者、策略、适配器、装饰器等的核心思想、适用场景和优缺点远比背诵定义要重要。面试官更希望看到你如何运用模式思想去解决实际问题。最后建议你找一个小项目或者回顾一下自己写过的代码尝试用今天学到的模式去重新思考设计。实践出真知用起来这些知识才能真正变成你自己的。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。