设计模式基础（1）

目录

一、设计模式的定义

二、设计模式的三大类别

三、设计模式的原则

四、主要设计模式目录

4.1 创建型模式（Creational Patterns）

4.2 结构型模式（Structural Patterns）

4.3 行为型模式（Behavioral Patterns）

---

一、设计模式的定义

设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。这些模式代表了最佳实践，通常由有经验的面向对象的软件开发人员采用，以解决在软件设计过程中经常遇到的一般问题。

设计模式提供了一种通用的语言和框架，使得开发者可以更高效地沟通复杂的系统架构，并且允许他们复用已有的解决方案来避免重新发明轮子。每种设计模式都描述了一个在软件开发中不断重复出现的问题，以及解决这个问题的核心思想。它们有助于提高代码的可读性、可维护性和可靠性，并使软件工程更加工程化和规范化。

二、设计模式的三大类别

设计模式分为三大类：创建型模式（关注对象的创建）、结构型模式（关注对象之间的组合）和行为型模式（关注对象之间的交互和职责分配）。

大家在看一些资料的时候，会发现，有人特意提到J2EE类设计模式。这通常指的是在Java 2平台企业版（Java 2 Platform, Enterprise Edition，简称J2EE）中使用的一系列设计模式。这些设计模式是针对开发企业级应用的特殊需求而提出的，它们可能并不属于经典的Gang of Four (GoF)设计模式分类中的三大类：创建型、结构型和行为型。

因此，说“J2EE设计模式”是一种单独的设计模式类别或子集是合理的。这主要是因为J2EE应用程序有其独特的架构特点和挑战，比如处理多层体系结构、分布式计算、事务管理、安全性等。为了解决这些问题，开发者们总结了一系列特定于J2EE环境的最佳实践，这些实践有时被称为“J2EE设计模式”。

需要注意的是，随着技术的发展，特别是Java平台从J2EE到Java EE（Java Platform, Enterprise Edition），再到现在的Jakarta EE（由Eclipse基金会维护的企业级Java规范），一些早期与J2EE相关的模式可能会发生变化或不再适用。同时，新的模式也可能出现以适应新的技术和框架。

比如，大家都熟知的MVC设计模式，这可是初学JAVA必须领会的模式，比如经典的Struts框架，就是基于MVC设计模式。MVC（Model-View-Controller）模式是软件工程中的一种经典架构模式，它在J2EE时代就已经被广泛采用，并且对后续的Web开发框架和企业级应用有着深远的影响。然而，随着技术的发展，尤其是从J2EE到Java EE再到Jakarta EE的过程中，许多新的编程模型和框架出现了，它们提供了不同的方式来组织和管理应用程序的结构。

虽然 MVC 仍然是一种有效的设计原则，但它可能不再像以前那样直接映射到现代 Java 框架中的组件。例如，在Spring框架中，尽管基本的概念类似于MVC，但实现方式却有所差异，比如通过DispatcherServlet处理请求、使用@Controller和@RequestMapping注解来定义控制器行为等。

此外，其他现代前端框架，如AngularJS、React或Vue.js，它们也采用了类似的模式，但具体实现和分工与传统的MVC有所不同。这些框架通常将视图和控制器的职责合并在一起，而模型则负责处理数据和业务逻辑。

因此，说MVC模式不再适合所有情况并不完全准确。它的核心思想——分离关注点，仍然是现代软件设计中的重要原则。只不过，随着时间的推移，这种思想可能会以不同的形式体现出来，或者与其他模式组合起来形成更复杂的架构。开发者需要根据具体的项目需求和技术选型来决定最适合的架构模式。

三、设计模式的原则

以下是几个在软件工程中常用的设计原则：

1. 单一职责原则（Single Responsibility Principle, SRP）
   - 一个类或模块应该只有一个改变的原因。
   - 这个原则强调了将代码的职责划分得尽可能清晰和独立。

2. 开闭原则（Open-Closed Principle, OCP）
   - 对扩展开放，对修改关闭。
   - 这个原则建议通过抽象来实现代码的可扩展性，而尽量避免直接修改现有代码。

3. 里氏替换原则（Liskov Substitution Principle, LSP）
   - 子类型必须能够替换其基类型。
   - 这个原则要求在继承体系中，子类应当可以无限制地替代父类，并且不会导致错误或异常。

4. 接口隔离原则（Interface Segregation Principle, ISP）
   - 客户端不应该被迫依赖于他们不需要的方法。
   - 这个原则提倡创建更小、更专业的接口，而不是大型、通用的接口。

5. 依赖倒置原则（Dependency Inversion Principle, DIP）
   - 高层模块不应该依赖低层模块，两者都应该依赖抽象。
   - 抽象不应该依赖细节，细节应该依赖于抽象。
   - 这个原则有助于提高代码的灵活性和可维护性。

6. 合成复用原则（Composite Reuse Principle, CRP）
   - 尽量使用对象组合，而不是继承来达到复用的目的。
   - 这个原则鼓励使用关联关系来实现代码复用，从而降低耦合度。

7. 迪米特法则（Law of Demeter, LoD）或最少知道原则
   - 一个对象应该对其他对象有尽可能少的了解。
   - 这个原则旨在减少模块之间的耦合度，提高代码的可读性和可维护性。

8. 契约式编程（Programming by Contract, PBC）
   - 类和方法之间应有明确的约定（契约），包括前置条件、后置条件和不变条件。
   - 这个原则可以帮助确保代码的正确性和可靠性。

9. 命令查询分离原则（Command-Query Separation, CQS）
   - 方法要么改变对象的状态（命令），要么返回结果（查询），但不能同时做这两件事。
   - 这个原则有助于提高代码的可预测性和可测试性。

以上这些原则都是为了帮助开发者编写出更加健壮、可读、可维护和可扩展的代码。在实际项目中，需要根据具体场景灵活应用这些原则，并与其他设计原则相平衡。

四、主要设计模式目录

4.1 创建型模式（Creational Patterns）

创建型设计模式是用于处理对象的创建过程，它们将对象的实例化和使用解耦。以下是创建型模式中的一些主要模式：

1. 工厂方法（Factory Method）
   - 定义一个用于创建对象的接口，让子类决定实例化哪一个类。
   - 使得一个类的实例化延迟到其子类。

2. 抽象工厂（Abstract Factory）
   - 提供一个创建一系列相关或相互依赖对象的接口，而无需指定具体的类。
   - 适用于需要提供多个相关的对象系列的情况。

3. 建造者（Builder）
   - 将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
   - 适用于需要生成的产品有多种表现形式或者组装方式时。

4. 原型（Prototype）
   - 提供了一个从现有对象复制新对象的方法，而不是通过new操作符直接创建新的对象。
   - 当系统需要大量创建相似对象，而且创建过程很耗时的时候，适合使用此模式。

5. 单例（Singleton）
   - 确保一个类只有一个实例，并且提供一个全局访问点。
   - 适用于只需要一个实例来协调系统的某些活动的情况。

这些模式的主要目的是隐藏对象的创建细节，使得代码更加灵活和可扩展，同时减少了代码之间的耦合度。在实际开发中，根据具体的需求和场景选择合适的创建型模式可以使代码更加健壮和易于维护。

4.2 结构型模式（Structural Patterns）

结构型设计模式关注于对象和类的组合方式，它们提供了如何将对象组织在一起以便更好地实现系统功能的方法。以下是结构型模式中的一些主要模式：

1. 适配器（Adapter）
   - 将一个类的接口转换成客户希望的另一个接口。
   - 使得原本不兼容的类可以一起工作。

2. 桥接（Bridge）
   - 将抽象部分与它的实现部分分离，使它们都可以独立地变化。
   - 提供了一种将抽象部分和实现部分解耦的方式。

3. 装饰器（Decorator）
   - 动态地给一个对象添加一些额外的职责。
   - 提供一种比继承更有弹性的替代方案来扩展对象的功能。

4. 外观（Facade）
   - 为子系统中的一组接口提供一个一致的界面。
   - 它定义了一个高层接口，使得子系统更容易使用。

5. 享元（Flyweight）
   - 使用共享技术有效地支持大量细粒度的对象。
   - 减少内存使用并提高程序性能。

6. 代理（Proxy）
   - 为其他对象提供一种代理以控制对这个对象的访问。
   - 可以用于创建轻量级的对象或延迟加载、权限检查等场景。

这些模式通过改变对象间的组合关系，提高了代码的复用性、灵活性和可扩展性，并降低了系统的复杂性。在实际开发中，根据具体的需求和场景选择合适的结构型模式可以使代码更加健壮和易于维护。

4.3 行为型模式（Behavioral Patterns）

行为型设计模式关注于对象之间的通信和责任分配，它们描述了如何在类或对象之间划分算法的职责。以下是行为型模式中的一些主要模式：

1. 模板方法（Template Method）
   - 在一个抽象类中定义了一个算法的框架，而将一些步骤延迟到子类中。
   - 它允许子类在不改变结构的情况下重定义算法的特定步骤。

2. 命令（Command）
   - 将一个请求封装为一个对象，从而使用户可以使用不同的请求、队列或者日志请求，同时还可以支持可撤销的操作。
   - 通过将操作与接收者分离，使得新的请求类型易于添加。

3. 策略（Strategy）
   - 定义了一系列算法，并将每一个算法封装起来，让它们可以相互替换。
   - 策略模式让算法的变化独立于使用该算法的客户。

4. 责任链（Chain of Responsibility）
   - 允许将请求沿着处理者链传递，直到被处理为止。
   - 消除请求发送者和接收者之间的耦合关系。

5. 状态（State）
   - 允许对象在内部状态变化时改变其行为。
   - 当控制流基于对象的状态时，使用状态模式更合适。

6. 观察者（Observer）
   - 定义了一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都会得到通知并自动更新。
   - 提供了一种对象间的一对多发布/订阅机制。

7. 访问者（Visitor）
   - 表示一个作用于某元素结构中的各元素的操作。
   - 它使你可以在不修改各元素类的前提下定义作用于这些元素的新操作。

8. 备忘录（Memento）
   - 在不破坏封装性的前提下，捕获一个对象的内部状态以便稍后恢复它。
   - 提供了一种状态保存和回滚的方法。

9. 中介者（Mediator）
   - 定义一个中介对象来封装一系列的对象交互。
   - 降低了系统的复杂性和耦合度。

10. 迭代器（Iterator）
    - 提供一种顺序访问聚合对象的元素的方式，而不暴露其底层表示。
    - 支持以统一的方式遍历各种数据结构。

11. 解释器（Interpreter）
    - 给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
    - 当需要实现一个小规模的语言或者表达式解析时，适合使用此模式。

这些模式通过合理地组织对象间的交互，提高了代码的复用性、灵活性和可扩展性，并简化了复杂的系统设计。在实际开发中，根据具体的需求和场景选择合适的行为型模式可以使代码更加健壮和易于维护。

先整理这么多，后面我们有时间详细一起学习几个常用的设计模式。