《设计模式》第一篇：初识

本期内容为自己总结归档，共分6章，本人遇到过的面试问题会重点标记。

《设计模式》第一篇：初识

《设计模式》第二篇：单例模式

《设计模式》第三篇：工厂模式

《设计模式》第四篇：观察模式

《设计模式》第五篇：策略模式

《设计模式》第六篇：装饰器模式

《设计模式》第七篇：适配器模式

《设计模式》第八篇：创建型模式

《设计模式》第九篇：结构型模式

《设计模式》第十篇：行为型模式

《设计模式》第十一篇：总结&常用案例

(若有任何疑问，可在评论区告诉我，看到就回复)

第一章：设计模式为什么重要？

1.1 一个真实世界的困境：电商订单系统的演进

让我们从一个简单的电商订单系统开始。最初的版本非常简单：

public class Order {
private double amount;

public double calculateTotal() {
return amount; // 最初只有商品价格
}
}

随着业务发展，我们需要添加运费：

public class Order {
private double amount;
private double shippingFee;

public double calculateTotal() {
return amount + shippingFee;
}
}

接着要添加税费、优惠券、会员折扣…

public class Order {
private double amount;
private double shippingFee;
private double tax;
private double couponDiscount;
private boolean isVIP;

public double calculateTotal() {
double total = amount + shippingFee + tax;

if (couponDiscount > 0) {
total -= couponDiscount;
}

if (isVIP) {
total *= 0.9; // VIP 9折
}

return total;
}
}

这就是典型的“代码坏味道”——每当有新需求时，我们都在不断修改同一个类，添加更多的条件判断。这种代码有几个严重问题：

1.2 设计模式的救赎：重构后的优雅设计

如果我们应用设计模式来重构这个系统，会变成什么样？

// 策略模式：不同的折扣策略
public interface DiscountStrategy {
double applyDiscount(double amount);
}

public class VIPDiscount implements DiscountStrategy {
public double applyDiscount(double amount) {
return amount * 0.9;
}
}

public class CouponDiscount implements DiscountStrategy {
private double couponValue;

public double applyDiscount(double amount) {
return amount – couponValue;
}
}

// 装饰器模式：动态添加费用
public abstract class OrderDecorator {
protected Order order;

public OrderDecorator(Order order) {
this.order = order;
}

public abstract double calculateTotal();
}

public class ShippingFeeDecorator extends OrderDecorator {
public ShippingFeeDecorator(Order order) {
super(order);
}

public double calculateTotal() {
return order.calculateTotal() + 10.0; // 基础运费
}
}

通过这样的重构，我们获得了：

• 可扩展性：添加新折扣类型不需要修改现有代码

• 可测试性：每个策略都可以独立测试

• 可维护性：每个类职责单一，易于理解和修改

1.3 设计模式的核心价值

设计模式的价值远不止于代码组织，它还在以下几个层面带来深远影响：

1.3.1 提升沟通效率

想象两个开发者之间的对话：

没有设计模式：

"我需要一个类，这个类只能创建一个实例，全局访问，还要考虑多线程安全…"

有设计模式：

"这里用单例模式。"

设计模式提供了共享的词汇表，让开发者可以用更少的词汇表达更复杂的概念。

1.3.2 加速学习曲线

当我加入一个新的团队时，如果看到代码中使用了熟悉的模式，我能更快地理解系统架构。设计模式就像是软件架构的通用设计模式语言，降低了新人理解系统的门槛。

1.3.3 避免重复造轮子

很多设计问题是通用的。设计模式记录了经过验证的解决方案，让我们可以直接站在巨人的肩膀上，而不是从零开始摸索。

第二章：设计模式全景概览

2.1 设计模式的起源：GOF 23种模式

设计模式的概念最早出现在建筑领域。建筑师克里斯托弗·亚历山大在《建筑的永恒之道》中提出：许多建筑问题都有共同的解决方案模式。

1994年，Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides四位作者（被称为"四人帮"或GOF）出版了《设计模式：可复用面向对象软件的基础》，系统地提出了23种设计模式。

这23种模式被分为三大类，下面是它们的全景图：

​

2.2 创建型模式：优雅地创建对象

创建型模式专注于对象的创建机制，帮助我们更灵活、更合理地创建对象实例。

核心思想：解耦对象的创建与使用

想象一个汽车制造厂。司机不需要知道汽车是如何制造的，只需要知道如何驾驶。同样，在软件中，创建型模式将对象的创建过程封装起来，让使用者无需关心创建细节。

​

⭐常用创建型模式对比：

2.3 结构型模式：构建灵活的结构

结构型模式关注如何将类或对象组合成更大的结构，同时保持结构的灵活和高效。

核心思想：组合优于继承

在面向对象设计中，继承是最常见的代码复用方式。但过度使用继承会导致：

结构型模式提倡使用组合来替代继承，提供更大的灵活性。

​

⭐常用结构型模式对比：

2.4 行为型模式：对象间的协作与职责分配

行为型模式关注对象之间如何交互、如何分配职责，以及算法的封装。

核心思想：将变化的部分封装起来

软件中最难维护的部分就是经常变化的部分。行为型模式将这些变化封装在独立的类中，使系统更加稳定和灵活。

​

⭐常用行为型模式对比：

2.5 ⭐设计模式的基石：SOLID原则

在深入学习具体模式之前，理解SOLID原则至关重要。这些原则是设计模式的理论基础和指导思想。

​

2.5.1 单一职责原则（SRP）

一个类应该只有一个引起它变化的原因。

优点：

• 功能单一，职责清晰。
• 增强可读性，方便维护

缺点：

• 拆分的太详细，类的数量会急剧增加。
• 职责的的度量没有统一的标准，需要根据项目实现情况而定。

违反SRP的例子：

public class UserService {
// 用户验证
public boolean validateUser(String username, String password) { … }

// 数据库操作
public void saveUser(User user) { … }

// 发送邮件
public void sendEmail(User user, String message) { … }
}

遵循SRP的重构：

public class UserValidator { … }
public class UserRepository { … }
public class EmailService { … }

2.5.2 开闭原则（OCP）

软件实体应该对扩展开放，对修改关闭。

        这是我们文章开头订单系统的核心问题。通过策略模式和装饰器模式，我们成功地遵循了OCP原则：当需要新的折扣类型或费用类型时，我们扩展新的类，而不是修改现有代码。

2.5.3 里氏替换原则（LSP）

子类型必须能够替换它们的父类型。

        这意味着任何父类出现的地方，子类都应该能够无缝替换。这个原则确保了继承关系的正确使用。

违反LSP的例子：

class Rectangle {
protected int width, height;

public void setWidth(int width) { this.width = width; }
public void setHeight(int height) { this.height = height; }
}

class Square extends Rectangle {
// 正方形要求宽高相等
@Override
public void setWidth(int width) {
super.setWidth(width);
super.setHeight(width);
}

@Override
public void setHeight(int height) {
super.setWidth(height);
super.setHeight(height);
}
}

这里Square无法完美替换Rectangle，因为设置宽高的行为不一致。

2.5.4 接口隔离原则（ISP）

客户端不应该被迫依赖它们不使用的接口。

将庞大的接口拆分为更小、更具体的接口，让客户端只需知道它们真正需要的方法。

2.5.5 依赖倒置原则（DIP）

高层模块不应该依赖低层模块，两者都应该依赖抽象。

这是实现松耦合的关键。通过依赖抽象（接口或抽象类），而不是具体实现，我们的系统变得更加灵活。

第三部分：如何学习设计模式

3.1 学习路径建议

学习设计模式不是一蹴而就的过程。我建议按照以下路径循序渐进：

​

3.2 避免常见误区

在学习设计模式的过程中，有几个常见误区需要警惕：

误区1：为了使用模式而使用模式

这是最常见的错误。设计模式是解决特定问题的工具，不是必须遵循的教条。如果简单代码就能解决问题，就不要强行使用模式。

反例：

// 过度设计的单例模式
public class SimpleConfig {
private static volatile SimpleConfig instance;
private static final Object lock = new Object();

private SimpleConfig() {
// 私有构造器
}

public static SimpleConfig getInstance() {
if (instance == null) {
synchronized (lock) {
if (instance == null) {
instance = new SimpleConfig();
}
}
}
return instance;
}

// 实际上只有一个简单的配置项
private String config = "default";

public String getConfig() { return config; }
}

如果配置确实简单且不需要延迟初始化，直接使用静态变量可能更清晰。

误区2：过度设计，过早优化

"将来可能需要"是一个危险的信号。遵循YAGNI原则（You Ain't Gonna Need It），只有在真正需要时才引入复杂性。

误区3：死记硬背模式结构

理解模式的意图和适用场景比记住UML图更重要。同样的模式在不同场景下可能有不同的实现方式。

第四部分：从理论到实践：设计模式在真实项目中的应用

让我们看一个综合案例，展示多个设计模式如何协同工作。

4.1 场景：电商平台通知系统

需求：电商平台需要向用户发送各种通知（订单确认、发货通知、促销信息），支持多种渠道（短信、邮件、App推送），并且可以灵活添加新渠道。

初始设计（存在问题的版本）：

public class NotificationService {
public void send(String message, String type, String channel) {
if ("order".equals(type)) {
if ("sms".equals(channel)) {
// 发送订单短信
System.out.println("发送订单短信: " + message);
} else if ("email".equals(channel)) {
// 发送订单邮件
System.out.println("发送订单邮件: " + message);
}
// 更多条件判断…
} else if ("promotion".equals(type)) {
// 更多条件判断…
}
// 每增加一种类型或渠道，就要添加更多if-else
}
}

重构后的设计（应用多种模式）：

// 策略模式：不同的消息类型
public interface MessageType {
String format(String content);
}

public class OrderMessage implements MessageType {
public String format(String content) {
return "[订单] " + content;
}
}

public class PromotionMessage implements MessageType {
public String format(String content) {
return "[促销] " + content;
}
}

// 策略模式：不同的发送渠道
public interface Channel {
void send(String formattedMessage);
}

public class SMSChannel implements Channel {
public void send(String formattedMessage) {
System.out.println("通过短信发送: " + formattedMessage);
}
}

public class EmailChannel implements Channel {
public void send(String formattedMessage) {
System.out.println("通过邮件发送: " + formattedMessage);
}
}

// 工厂模式：创建不同类型的消息处理器
public class MessageProcessorFactory {
public static MessageProcessor createProcessor(String type) {
switch (type) {
case "order":
return new OrderProcessor();
case "promotion":
return new PromotionProcessor();
default:
throw new IllegalArgumentException("未知的消息类型");
}
}
}

// 观察者模式：当需要添加新功能时（如日志记录、数据统计）
public abstract class MessageObserver {
public abstract void onMessageSent(String message);
}

public class LoggingObserver extends MessageObserver {
public void onMessageSent(String message) {
System.out.println("记录日志: " + message);
}
}

// 主服务类，现在变得非常简洁
public class NotificationService {
private List<Channel> channels = new ArrayList<>();
private List<MessageObserver> observers = new ArrayList<>();

public void send(String content, String type) {
MessageProcessor processor = MessageProcessorFactory.createProcessor(type);
String formattedMessage = processor.process(content);

for (Channel channel : channels) {
channel.send(formattedMessage);
}

for (MessageObserver observer : observers) {
observer.onMessageSent(formattedMessage);
}
}

public void addChannel(Channel channel) {
channels.add(channel);
}

public void addObserver(MessageObserver observer) {
observers.add(observer);
}
}

这个重构后的设计具有以下优点：

总结：开始设计模式之旅

设计模式不是高深莫测的理论，而是解决实际开发问题的实用工具集。总结一下：

记住，设计模式的最终目标不是写出"符合模式"的代码，而是写出清晰、可维护、可扩展的代码。模式只是达到这个目的的手段之一。

        在接下来的系列文章中，我们将深入探讨每个核心模式，通过更多真实案例帮助你真正掌握这些强大的工具。