alankuo的专栏

教师可以通过课程对象的方法间接获取与课程相关的学生信息，而不是直接与学生对象进行交互。- “直接的朋友”是指当前对象本身、通过方法参数传入的对象、当前对象所创建的对象、当前对象的实例变量所引用的对象等。- 一个对象不应该过度依赖其他对象的内部细节，应该通过有限的接口与其他对象进行交互，以降低对象之间的耦合度。- 提高软件的可维护性和可扩展性：当一个模块发生变化时，对其他模块的影响较小，降低了修改代码带来的风险。定义：一个对象应该对其他对象有尽可能少的了解，只与直接的朋友通信。

如果有一个只需要打印功能的设备，那么它不应该实现这个包含了扫描和复印方法的接口，而应该有一个只包含打印方法的小接口。- 一个接口应该只服务于一个子模块或业务逻辑，避免一个接口包含过多的业务逻辑，导致实现类的职责不清晰。- 提高代码的可维护性：接口变小后，更容易理解和修改，当需要修改某个接口时，影响的范围也会更小。- 降低代码的耦合度：实现类只依赖于它真正需要的接口，减少了不必要的依赖，降低了代码的耦合度。- 增强代码的可复用性：小而专一的接口更容易被不同的实现类复用，提高了代码的复用程度。

如果遵循里氏替换原则，那么可以传入 Rectangle 或 Circle 的对象，程序都能正确运行，而不会因为传入不同的子类对象而出现错误。如果违反里氏替换原则，比如在子类中修改了父类已实现方法的行为，可能会导致在使用父类的地方出现意外的结果。例如，在父类 Shape 中有一个计算面积的方法，子类 Rectangle 正确实现了计算矩形面积的方法，但子类 Circle 在计算面积时返回了错误的值，那么在使用 Shape 类型的地方就可能会出现错误的结果。后置条件（返回值）可以被缩小但不能被放大。

比如有一个图形绘制的系统，最初只有绘制圆形和矩形的功能。如果要添加绘制三角形的功能，按照开闭原则，不应该修改已有的绘制圆形和矩形的代码，而是创建一个新的三角形绘制类来实现新功能。- 提高软件的可复用性：符合开闭原则的代码通常具有更高的可复用性，因为它们可以在不修改的情况下被用于不同的场景。- 增强软件的可扩展性：可以很容易地通过添加新的代码来满足新的需求，而不需要对整个系统进行大规模的修改。- 提高软件的可维护性：由于不修改已有的代码，所以不会影响到现有功能的稳定性，降低了引入新错误的风险。

比如有一个表示用户信息的类 UserInfo ，它不应该既负责用户信息的存储（如数据库操作），又负责用户信息的展示（如界面显示逻辑）。1. 提高代码的可维护性：当一个类只负责一个职责时，如果需要修改这个职责相关的代码，只需要在这个类中进行修改，而不会影响到其他不相关的功能模块。3. 降低代码的耦合度：每个类只关注自己的职责，不与其他职责过多地耦合，这样可以使系统更容易进行扩展和修改。2. 增强代码的可读性：类的功能单一，使得代码更易于理解，其他开发人员能够快速了解类的作用和用途。

依赖倒置原则（Dependency Inversion Principle，DIP）是软件工程中的一个重要原则。它的核心思想是：高层模块不应该依赖于低层模块，二者都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象。常见的实现方式是使用接口或抽象类来定义模块之间的交互契约。

例如，一个类 A 中的方法需要调用类 B 的方法，应该通过类 A 能够直接访问的对象来调用类 B 的方法，而不是直接去获取类 B 的实例并调用其方法。例如，一个类实现了一个大而全的接口，但实际上只需要其中的一部分方法，这样会导致该类被迫实现一些不需要的方法，增加了类的复杂性。比如，在一个分层架构的系统中，上层的业务逻辑层不应该直接依赖下层的数据访问层的具体实现类，而是应该依赖数据访问层的接口。例如，有一个函数接收一个父类类型的参数，如果传入一个子类对象，函数应该能够正常工作，并且不会出现意外的结果。

建造者模式（Builder Pattern）是一种创建型设计模式，将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。3. 具体建造者（ConcreteBuilder）：实现抽象建造者的方法，负责构建产品的各个部分。在上述示例中，通过不同的具体建造者和指挥者的协作，可以创建出具有不同部件组合的产品对象。4. 指挥者（Director）：负责按照一定的顺序调用建造者的方法来构建产品。2. 抽象建造者（Builder）：定义了创建产品各个部件的抽象方法。// 具体建造者 1。

4. 具体工厂（ConcreteFactory）：实现抽象工厂的工厂方法，创建并返回具体的产品对象。1. 符合开闭原则，增加新的产品时，只需增加相应的具体产品类和具体工厂类，无需修改原有代码。3. 抽象工厂（Factory）：声明创建抽象产品的工厂方法，该方法返回一个抽象产品类型。在上述示例中，通过具体工厂来创建对应的具体产品，客户端只需要与抽象工厂和抽象产品打交道。2. 具体产品（ConcreteProduct）：实现抽象产品的具体类。2. 将产品的创建和使用分离，使用者无需关心产品的创建细节。

建造者模式（Builder Pattern）是一种创建型设计模式，将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。3. 具体建造者（ConcreteBuilder）：实现抽象建造者的方法，负责构建产品的各个部分。在上述示例中，通过不同的具体建造者和指挥者的协作，可以创建出具有不同部件组合的产品对象。4. 指挥者（Director）：负责按照一定的顺序调用建造者的方法来构建产品。2. 抽象建造者（Builder）：定义了创建产品各个部件的抽象方法。// 具体建造者 1。

在上述示例中， Facade 类为客户端提供了一个统一的接口 complexOperation ，隐藏了子系统中各个类的具体操作细节。门面模式（Facade Pattern）是一种结构型设计模式，它为子系统中的一组接口提供一个统一的高层接口，使得子系统更容易使用。1. 门面（Facade）：为调用方提供一个简单的接口，隐藏了子系统的复杂性。2. 子系统（Subsystem）：一组复杂的、相互关联的类或模块。2. 对客户端隐藏了子系统的细节，简化了客户端的调用。

装饰模式（Decorator Pattern）是一种结构型设计模式，允许向一个现有的对象添加新的功能，同时又不改变其结构。3. 抽象装饰（Decorator）：继承了抽象构件，包含了一个指向抽象构件对象的引用，并实现了与抽象构件一致的接口。2. 具体构件（ConcreteComponent）：定义了一个具体的对象，实现了抽象构件接口。4. 具体装饰（ConcreteDecorator）：具体的装饰对象，向组件添加特定的职责。在上述示例中，通过装饰器可以不断为原始对象添加新的功能，而无需修改原始对象的代码。

原型模式（Prototype Pattern）是一种创建型设计模式，它通过复制一个现有对象来创建新的对象，而无需知道对象创建的具体细节。在上述示例中， ConcretePrototype 类实现了克隆自身的方法，通过调用 clone 方法创建新的对象。2. 避免子类化的复杂性：有时创建对象的过程比较复杂，使用原型模式可以避免通过子类化来创建对象的复杂过程。1. 性能优化：对于创建复杂对象或创建过程耗时的对象，通过复制原型对象可以提高创建新对象的效率。

1. 组件（Component）：这是一个抽象类或接口，为组合中的对象声明接口，定义了一些公共的操作，如 add 、 remove 、 getChild 等。3. 组合节点（Composite）：表示包含子节点的组合对象，存储子节点，并实现了组件接口中定义的操作，包括管理子节点的方法。在上述示例中，我们创建了一个树形结构，通过组合模式可以统一地对叶子节点和组合节点进行操作。2. 叶子节点（Leaf）：表示叶节点对象，没有子节点，实现了组件接口中定义的操作。

3. 代理主题（Proxy）：包含对真实主题的引用，从而可以在需要的时候操作真实主题对象；代理对象在客户端和真实主题对象之间起到中介的作用，并且可以控制对真实主题对象的访问。1. 抽象主题（Subject）：定义了真实主题和代理主题的公共接口，这样在任何使用真实主题的地方都可以使用代理主题。代理模式（Proxy Pattern）是一种结构型设计模式，它为其他对象提供一种代理以控制对这个对象的访问。1. 可以在不修改目标对象的基础上，通过代理对象对目标对象进行功能扩展。

备忘录模式（Memento Pattern）是一种行为型设计模式，用于捕获一个对象的内部状态，并在该对象之外保存这个状态，以便在需要时能够将对象恢复到先前保存的状态。2. 备忘录（Memento）：存储原发器的内部状态，备忘录对象应该被设计为原发器的私有内部类，以确保其状态的封装性和安全性。1. 原发器（Originator）：创建并使用备忘录来保存其内部状态，原发器可以根据需要决定保存哪些内部状态。1. 保持了原发器对象的封装性，负责人只能看到备忘录的窄接口，无法访问原发器的内部状态细节。

5. 对象结构（Object Structure）：能枚举它的元素，可以提供一个高层的接口以允许访问者访问它的元素。在访问者模式中，我们将数据结构和作用于结构上的操作分离，使得在不修改数据结构的前提下，可以定义新的操作。2. 具体访问者（Concrete Visitor）：实现抽象访问者声明的各种操作。4. 具体元素（Concrete Element）：实现接受访问者的方法。1. 抽象访问者（Visitor）：声明访问者可以对每类元素进行的操作。3. 抽象元素（Element）：声明接受访问者的方法。

观察者模式（Observer Pattern）是一种行为型设计模式，用于定义对象之间的一对多依赖关系，当一个对象的状态发生改变时，它的所有依赖者（观察者）都会收到通知并自动更新。1. 实现了对象之间的松散耦合，主题不需要知道具体的观察者，观察者也不需要知道主题的内部细节。1. 主题（Subject）：拥有一些重要的状态，当状态发生改变时，会通知所有的观察者。2. 观察者（Observer）：接收主题的通知并进行相应的更新操作。在实际应用中，观察者模式常用于实现事件驱动的系统、发布/订阅系统等。

在上述示例中， prepareBeverage 方法就是模板方法，定义了制作饮料的整体流程，而 brew 和 addCondiments 则是留给子类去具体实现的步骤。在模板方法模式中，一个抽象类公开定义了执行某种算法的模板框架。这个框架中的某些步骤是抽象的，由子类去实现。而模板方法本身则定义了算法的结构，把一些特定步骤的实现延迟到子类中。2. 扩展性：子类可以根据需要重写特定的步骤，而不影响整体算法的结构。3. 封装性：将算法的实现细节封装在子类中，保持了父类的简洁和稳定。

在上述示例中， Flyweight 是享元接口， ConcreteFlyweight 是具体的享元类， FlyweightFactory 用于管理享元对象的创建和共享。享元模式主要用于当系统中存在大量相似对象时，如果每个对象都单独创建和存储，会消耗大量的内存和资源。通过享元模式，可以将对象的公共部分提取出来共享，只在必要时创建独特的部分。2. 对象的大部分状态可以外部化，并且可以在使用时传入。1. 减少内存消耗，特别是在创建大量相似对象的场景中。2. 提高性能，避免了不必要的对象创建和销毁。

在上述示例中， Target 是目标接口， Adaptee 是具有不同接口的类， Adapter 类将 Adaptee 的接口转换为 Target 接口，从而使得客户端能够以统一的方式使用原本不兼容的接口。适配器模式（Adapter Pattern）是一种结构型设计模式，它的主要作用是将一个类的接口转换成客户端所期望的另一个接口。2. 当需要创建一个可复用的类，该类可以与不相关或不可预见的类协同工作。// 适配器类，将 Adaptee 的接口适配成 Target 接口。

解释器模式（Interpreter Pattern）是一种行为型设计模式，用于定义一个语言的语法表示，并提供一个解释器来解释该语言中的表达式。- buildExpression 方法用于根据输入的表达式字符串构建表达式对象的结构。1. 对于复杂的语法，解释器模式可能会导致类的数量过多，使系统变得复杂。2. 解释器模式的效率可能相对较低，特别是对于频繁执行的解释操作。2. 实现了语法和执行逻辑的分离，提高了代码的清晰度和可维护性。- 在 main 方法中，对给定的表达式进行解释并计算结果。

在实现迭代器模式时，通常会定义一个迭代器接口，规定了一些基本的遍历操作，如获取下一个元素、判断是否还有元素等。然后针对具体的聚合对象实现相应的迭代器类。迭代器模式在很多编程语言的标准库中都有广泛的应用，比如 Java 中的 Iterator 接口和各种集合类的迭代器实现。迭代器模式是一种常见的设计模式，用于顺序访问一个聚合对象的元素，而无需暴露该对象的内部表示。例如，对于一个数组或链表这样的聚合对象，可以创建一个专门的迭代器来实现遍历操作。1. 支持对聚合对象的多种遍历方式，而无需修改聚合对象的接口。

通过设置处理器之间的链接形成责任链，根据请求的值由相应的处理器进行处理。每个对象都有机会决定是否处理该请求，如果不能处理，则将请求传递给链中的下一个对象。例如，在一个请假审批流程中，可能有员工、经理、总监等多个审批环节，每个环节都是一个处理者，形成一个责任链。在使用责任链模式时，构建一个处理者的链，将请求从链的头部开始传递，直到有处理者能够处理为止。首先，定义一个抽象的处理者类，包含一个指向下一个处理者的引用和一个处理请求的抽象方法。然后，创建具体的处理者类，继承抽象处理者类，并实现具体的处理逻辑。

通过状态模式，我们将状态相关的行为封装在不同的状态类中，使得对象的行为更加清晰和易于维护。状态模式的核心思想是将对象的状态封装成独立的类，并在对象内部维护一个对当前状态对象的引用。当对象的状态发生变化时，通过切换当前的状态对象来实现不同的行为。状态模式（State Pattern）是一种行为型设计模式，它允许一个对象在其内部状态改变时改变它的行为。2. 状态模式的结构相对复杂，对于简单的状态管理可能会导致过度设计。2. 方便添加新的状态和对应的行为，具有良好的扩展性。1. 可能会增加系统中类的数量。

在上述示例中， Light 类是接收者， Command 是命令接口， LightOnCommand 和 LightOffCommand 是具体的命令类， RemoteControl 是调用者。例如，假设有一个电灯控制的场景，电灯是接收者，有打开和关闭电灯的操作。命令模式（Command Pattern）是一种行为设计模式，它将请求封装成对象，从而使请求的发送者和请求的执行者解耦。2. 具体命令（Concrete Command）：实现了命令接口，持有接收者对象，并定义了具体的执行逻辑。

策略模式（Strategy Pattern）是一种行为型设计模式，它定义了一系列算法，并将每个算法封装起来，使它们可以相互替换。策略模式让算法的变化独立于使用算法的客户端。2. 避免多重条件判断：将不同的算法封装在独立的类中，避免了在一个大方法中使用大量的条件判断来选择算法。它适用于当一个类在其操作中需要使用多种不同的算法，或者算法在未来可能会经常变化的情况。3. 提高代码的可读性和可维护性：算法的实现和使用分离，使得代码结构更清晰。1. 易于扩展：可以轻松添加新的策略而无需修改现有代码。

单例模式是一种常见的设计模式，确保一个类只有一个实例存在，并提供一个全局访问点来获取该实例。1. 可能导致全局状态：因为是全局唯一的，可能会隐藏一些依赖关系，使得代码难以理解和测试。单例模式常用于需要全局唯一控制或共享资源的场景，比如日志记录器、配置管理器等。2. 不利于并发：在多线程环境下，如果没有正确处理同步，可能会创建多个实例。1. 节省系统资源：只创建一个实例，减少了内存占用和对象创建销毁的开销。2. 全局访问：提供了一种简单的方式在整个应用程序中访问唯一的实例。// 静态私有成员，存储唯一实例。

在实际应用中，如果系统需要创建一系列相关的对象，并且希望在运行时动态地切换产品系列，抽象工厂模式是一个不错的选择。抽象工厂模式是一种创建型设计模式，它提供了一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。在上述代码中，通过抽象工厂模式，客户端不需要关心具体产品的创建细节，只需要与抽象工厂和抽象产品进行交互。1. 难以扩展新的产品：新增产品时需要修改抽象工厂的接口和所有相关的具体工厂类。2. 有利于产品的一致性：确保了一组相关产品的创建遵循统一的约束和规则。

在上述代码中， Implementor 是实现部分的接口， ConcreteImplementorA 和 ConcreteImplementorB 是具体的实现类。例如，假设有一个形状的抽象类 Shape 和一个颜色的抽象接口 Color。这样，无论增加新的形状或者新的颜色，都不需要修改已有的代码，只需要新增相应的类即可。这样，抽象类的方法可以通过调用实现类的方法来完成具体的功能。桥接模式的主要目的是将抽象与实现解耦，从而使得两者可以独立地进行扩展和修改，而不会相互影响。

在上述代码中， Product 是产品的抽象接口， ConcreteProductA 和 ConcreteProductB 是具体的产品实现。每个具体的工厂子类实现这个抽象方法来创建特定的产品对象。工厂模式是一种创建对象的设计模式，它提供了一种创建对象的方式，将对象的创建和使用分离，增加了代码的灵活性和可维护性。简单工厂模式：定义一个工厂类，有一个创建对象的方法，通过传入不同的参数来决定创建哪种具体的产品对象。抽象工厂模式：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

中介者模式（Mediator Pattern）是一种行为型设计模式，它通过引入一个中介者对象来封装一系列对象之间的交互，使这些对象不需要显式地相互引用，从而降低了对象之间的耦合度。中介者模式适用于多个对象之间复杂的交互关系，通过中介者进行集中管理，使系统更易于维护和扩展。

而对于计算不同的运费策略（按重量、按体积、固定费用等）可以使用策略模式。对于创建不同类型的订单（如普通订单、促销订单）可以使用工厂模式。类来创建不同的具体产品对象，客户端无需关心产品的具体创建过程。类使用策略来计算最终金额。