数字人生

意图：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。主要解决：一些方法通用，却在每一个子类都重新写了这一方法。何时使用：有一些通用的方法。如何解决：将这些通用算法抽象出来。关键代码：在抽象类实现，其他步骤在子类实现。应用实例：1、在造房子的时候，地基、走线、水管都一样，只有在建筑的后期才有加壁橱加栅栏等差异。2、西游记里面菩萨定好的 81 难，这就是一个顶层的逻辑骨架。

意图：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。主要解决：在有多种算法相似的情况下，使用 if…else 所带来的复杂和难以维护。何时使用：一个系统有许多许多类，而区分它们的只是他们直接的行为。如何解决：将这些算法封装成一个一个的类，任意地替换。关键代码：实现同一个接口。应用实例：1、诸葛亮的锦囊妙计，每一个锦囊就是一个策略。2、旅行的出游方式，选择骑自行车、坐汽车，每一种旅行方式都是一个策略。3、JAVA AWT 中的 LayoutManager。

意图：允许对象在内部状态发生改变时改变它的行为，对象看起来好像修改了它的类。主要解决：对象的行为依赖于它的状态（属性），并且可以根据它的状态改变而改变它的相关行为。何时使用：代码中包含大量与对象状态有关的条件语句。如何解决：将各种具体的状态类抽象出来。关键代码：通常命令模式的接口中只有一个方法。而状态模式的接口中有一个或者多个方法。而且，状态模式的实现类的方法，一般返回值，或者是改变实例变量的值。也就是说，状态模式一般和对象的状态有关。实现类的方法有不同的功能，覆盖接口中的方法。

定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。一个对象状态改变给其他对象通知的问题，而且要考虑到易用和低耦合，保证高度的协作。一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知，进行广播通知。使用面向对象技术，可以将这种依赖关系弱化。在抽象类里有一个 ArrayList 存放观察者们。1、拍卖的时候，拍卖师观察最高标价，然后通知给其他竞价者竞价。...

在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。所谓备忘录模式就是在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样可以在以后将对象恢复到原先保存的状态。很多时候我们总是需要记录一个对象的内部状态，这样做的目的就是为了允许用户取消不确定或者错误的操作，能够恢复到他原先的状态，使得他有"后悔药"可吃。通过一个备忘录类专门存储对象状态。客户不与备忘录类耦合，与备忘录管理类耦合。1、后悔药。2、打游戏时的存档。...

用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。对象与对象之间存在大量的关联关系，这样势必会导致系统的结构变得很复杂，同时若一个对象发生改变，我们也需要跟踪与之相关联的对象，同时做出相应的处理。多个类相互耦合，形成了网状结构。将上述网状结构分离为星型结构。对象 Colleague 之间的通信封装到一个类中单独处理。1、中国加入 WTO 之前是各个国家相互贸易，结构复杂，现在是各个国家通过 WTO 来互相贸易。...

提供一种方法顺序访问一个聚合对象中各个元素, 而又无须暴露该对象的内部表示。不同的方式来遍历整个整合对象。**何时使用：**遍历一个聚合对象。**如何解决：**把在元素之间游走的责任交给迭代器，而不是聚合对象。**关键代码：**定义接口：hasNext, next。**应用实例：**JAVA 中的 iterator。1、它支持以不同的方式遍历一个聚合对象。2、迭代器简化了聚合类。3、在同一个聚合上可以有多个遍历。4、在迭代器模式中，增加新的聚合类和迭代器类都很方便，无须修改原有代码。.........

给定一个语言，定义它的文法表示，并定义一个解释器，这个解释器使用该标识来解释语言中的句子。对于一些固定文法构建一个解释句子的解释器。如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题。构建语法树，定义终结符与非终结符。构建环境类，包含解释器之外的一些全局信息，一般是 HashMap。编译器、运算表达式计算。1、可扩展性比较好，灵活。2、增加了新的解释表达式的方式。3、易于实现简单文法。......

意图：将一个请求封装成一个对象，从而使您可以用不同的请求对客户进行参数化。主要解决：在软件系统中，行为请求者与行为实现者通常是一种紧耦合的关系，但某些场合，比如需要对行为进行记录、撤销或重做、事务等处理时，这种无法抵御变化的紧耦合的设计就不太合适。何时使用：在某些场合，比如要对行为进行"记录、撤销/重做、事务"等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将"行为请求者"与"行为实现者"解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。如何解决。...

意图：避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。主要解决：职责链上的处理者负责处理请求，客户只需要将请求发送到职责链上即可，无须关心请求的处理细节和请求的传递，所以职责链将请求的发送者和请求的处理者解耦了。何时使用：在处理消息的时候以过滤很多道。如何解决：拦截的类都实现统一接口。关键代码。...

意图：运用共享技术有效地支持大量细粒度的对象。主要解决：在有大量对象时，有可能会造成内存溢出，我们把其中共同的部分抽象出来，如果有相同的业务请求，直接返回在内存中已有的对象，避免重新创建。何时使用： 1、系统中有大量对象。2、这些对象消耗大量内存。3、这些对象的状态大部分可以外部化。4、这些对象可以按照内蕴状态分为很多组，当把外蕴对象从对象中剔除出来时，每一组对象都可以用一个对象来代替。5、系统不依赖于这些对象身份，这些对象是不可分辨的。如何解决。...

意图：为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。主要解决：降低访问复杂系统的内部子系统时的复杂度，简化客户端之间的接口。何时使用： 1、客户端不需要知道系统内部的复杂联系，整个系统只需提供一个"接待员"即可。2、定义系统的入口。如何解决：客户端不与系统耦合，外观类与系统耦合。关键代码：在客户端和复杂系统之间再加一层，这一层将调用顺序、依赖关系等处理好。应用实例。......

意图：动态地给一个对象添加一些额外的职责。就增加功能来说，装饰器模式相比生成子类更为灵活。主要解决：一般的，我们为了扩展一个类经常使用继承方式实现，由于继承为类引入静态特征，并且随着扩展功能的增多，子类会很膨胀。何时使用：在不想增加很多子类的情况下扩展类。如何解决：将具体功能职责划分，同时继承装饰者模式。关键代码： 1、Component 类充当抽象角色，不应该具体实现。2、修饰类引用和继承 Component 类，具体扩展类重写父类方法。......

意图：将对象组合成树形结构以表示"部分-整体"的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。主要解决：它在我们树型结构的问题中，模糊了简单元素和复杂元素的概念，客户程序可以像处理简单元素一样来处理复杂元素，从而使得客户程序与复杂元素的内部结构解耦。何时使用： 1、您想表示对象的部分-整体层次结构（树形结构）。2、您希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象。如何解决：树枝和叶子实现统一接口，树枝内部组合该接口。...

过滤器模式（Filter Pattern）或标准模式（Criteria Pattern）是一种设计模式，这种模式允许开发人员使用不同的标准来过滤一组对象，通过逻辑运算以解耦的方式把它们连接起来。这种类型的设计模式属于结构型模式，它结合多个标准来获得单一标准。...

意图将抽象部分与实现部分分离，使它们都可以独立的变化。主要解决在有多种可能会变化的情况下，用继承会造成类爆炸问题，扩展起来不灵活。何时使用实现系统可能有多个角度分类，每一种角度都可能变化。如何解决把这种多角度分类分离出来，让它们独立变化，减少它们之间耦合。关键代码抽象类依赖实现类。应用实例1、猪八戒从天蓬元帅转世投胎到猪，转世投胎的机制将尘世划分为两个等级，即灵魂和肉体，前者相当于抽象化，后者相当于实现化。生灵通过功能的委派，调用肉体对象的功能，使得生灵可以动态地选择。优点缺点使用场景。...

意图将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。主要解决主要解决在软件系统中，常常要将一些"现存的对象"放到新的环境中，而新环境要求的接口是现对象不能满足的。何时使用1、系统需要使用现有的类，而此类的接口不符合系统的需要。2、想要建立一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作，这些源类不一定有一致的接口。3、通过接口转换，将一个类插入另一个类系中。如何解决继承或依赖（推荐）。...

代理模式的定义由于某些原因需要给某对象提供一个代理以控制对该对象的访问。这时，访问对象不适合或者不能直接引用目标对象，代理对象作为访问对象和目标对象之间的中介。代理模式的主要优点有●代理模式在客户端与目标对象之间起到一个中介作用和保护目标对象的作用；●代理对象可以扩展目标对象的功能；●代理模式能将客户端与目标对象分离，在一定程度上降低了系统的耦合度，增加了程序的可扩展性其主要缺点是●代理模式会造成系统设计中类的数量增加。...

创建型模式（CreationalPattern）的主要特点是将对象的创建与使用分离，根据对象的创建与组合方式的不同，创建型模式可分为单例（Singleton）模式、原型（Prototype）模式、工厂方法（FactoryMethod）模式、抽象工厂（AbstractFactory）模式和建造者（Builder）模式5种。本实验的主要目的如下。1、了解5种“创建型模式”的定义、特点和工作原理。2、理解5种“创建型模式”的结构、实现和应用场景。...

建造者（Builder）模式的定义指将一个复杂对象的构造与它的表示分离，使同样的构建过程可以创建不同的表示，这样的设计模式被称为建造者模式。它是将一个复杂的对象分解为多个简单的对象，然后一步一步构建而成。它将变与不变相分离，即产品的组成部分是不变的，但每一部分是可以灵活选择的。该模式的主要优点如下1、封装性好，构建和表示分离。2、扩展性好，各个具体的建造者相互独立，有利于系统的解耦。...

抽象工厂（AbstractFactory）模式的定义是一种为访问类提供一个创建一组相关或相互依赖对象的接口，且访问类无须指定所要产品的具体类就能得到同族的不同等级的产品的模式结构。抽象工厂模式是工厂方法模式的升级版本，工厂方法模式只生产一个等级的产品，而抽象工厂模式可生产多个等级的产品。使用抽象工厂模式一般要满足以下条件。●系统中有多个产品族，每个具体工厂创建同一族但属于不同等级结构的产品。●系统一次只可能消费其中某一族产品，即同族的产品一起使用。...

在现实生活中社会分工越来越细，越来越专业化。各种产品有专门的工厂生产，彻底告别了自给自足的小农经济时代，这大大缩短了产品的生产周期，提高了生产效率。同样，在软件开发中能否做到软件对象的生产和使用相分离呢？能否在满足“开闭原则”的前提下，客户随意增删或改变对软件相关对象的使用呢？这就是本节要讨论的问题。在《简单工厂模式》一节我们介绍了简单工厂模式，提到了简单工厂模式违背了开闭原则，而“工厂方法模式”是对简单工厂模式的进一步抽象化，其好处是可以使系统在不修改原来代码的情况下引进新的产品，即满足开闭原则。....

现实生活中，原始社会自给自足（没有工厂），农耕社会小作坊（简单工厂，民间酒坊），工业革命流水线（工厂方法，自产自销），现代产业链代工厂（抽象工厂，富士康）。我们的项目代码同样是由简到繁一步一步迭代而来的，但对于调用者来说，却越来越简单。在日常开发中，凡是需要生成复杂对象的地方，都可以尝试考虑使用工厂模式来代替。注意。...

在有些系统中，为了节省内存资源、保证数据内容的一致性，对某些类要求只能创建一个实例，这就是所谓的单例模式。单例（Singleton）模式的定义：指一个类只有一个实例，且该类能自行创建这个实例的一种模式。例如，Windows 中只能打开一个任务管理器，这样可以避免因打开多个任务管理器窗口而造成内存资源的浪费，或出现各个窗口显示内容的不一致等错误。在计算机系统中，还有 Windows 的回收站、操作系统中的文件系统、多线程中的线程池、显卡的驱动程序对象、打印机的后台处理服务、应用程序的日志对象、数据库的连接池、

在有些系统中，存在大量相同或相似对象的创建问题，如果用传统的构造函数来创建对象，会比较复杂且耗时耗资源，用原型模式生成对象就很高效，就像孙悟空拔下猴毛轻轻一吹就变出很多孙悟空一样简单。原型（Prototype）模式的定义如下：用一个已经创建的实例作为原型，通过复制该原型对象来创建一个和原型相同或相似的新对象。在这里，原型实例指定了要创建的对象的种类。用这种方式创建对象非常高效，根本无须知道对象创建的细节。例如，Windows 操作系统的安装通常较耗时，如果复制就快了很多。在生活中复制的例子非常多，这里不一

结合前几节的内容，我们一共介绍了 7 种设计原则，它们分别为开闭原则、里氏替换原则、依赖倒置原则、单一职责原则、接口隔离原则、迪米特法则和合成复用原则。这 7 种设计原则是软件设计模式必须尽量遵循的原则，是设计模式的础。在实际开发过程中，并不是一定要求所有代码都遵循设计原则，而是要综合考虑人力、时间、成本、质量，不刻意追求完美，要在适当的场景遵循设计原则。这体现的是一种平衡取舍，可以帮助我们设计出更加优雅的代码结构。各种原则要求的侧重点不同，下面我们分别用一句话归纳总结软件设计模式的七大原则，如下表所示。实

合成复用原则是面向对象设计原则的 7 条原则中剩下的最后一条，下面我们将对其进行详细地介绍。合成复用原则（Composite Reuse Principle，CRP）又叫组合/聚合复用原则（Composition/Aggregate Reuse Principle，CARP）。它要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。。合成复用原则同里氏替换原则相辅相成的，两者都是开闭原则的具体实现规范。通常类的复用分为继承复用和合成复用两种，继承复用虽然有简单和易实现的优

前几节分别详细介绍了面向对象设计原则中的开闭原则、里氏替换原则、依赖倒置原则、单一职责原则和接口隔离原则，本节将详细介绍迪米特法则。迪米特法则（Law of Demeter，LoD）又叫作最少知识原则（Least Knowledge Principle，LKP)，产生于 1987 年美国东北大学（Northeastern University）的一个名为迪米特（Demeter）的研究项目，由伊恩·荷兰（Ian Holland）提出，被 UML 创始者之一的布奇（Booch）普及，后来又因为在经典著作《程序员

面向对象设计原则除了开闭原则、里氏替换原则、依赖倒置原则和单一职责原则以外，还有接口隔离原则、迪米特法则和合成复用原则。本节将详细介绍接口隔离原则。接口隔离原则（Interface Segregation Principle，ISP）要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法。2002 年罗伯特·C.马丁给“接口隔离原则”的定义是：客户端不应该被迫依赖于它不使用的方法（Clients should not be forced to depend on metho

单一职责原则（Single Responsibility Principle，SRP）又称单一功能原则，由罗伯特·C.马丁（Robert C. Martin）于《敏捷软件开发：原则、模式和实践》一书中提出的。这里的职责是指类变化的原因，单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分（There should never be more than one reason for a class to change）。该原则提出对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存

依赖倒置原则（Dependence Inversion Principle，DIP）是 Object Mentor 公司总裁罗伯特·马丁（Robert C.Martin）于 1996 年在 C++ Report 上发表的文章。依赖倒置原则的原始定义为：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象...

面向对象设计原则-02里氏替换原则里氏替换原则的定义里氏替换原则（Liskov Substitution Principle，LSP）由麻省理工学院计算机科学实验室的里斯科夫（Liskov）女士在 1987 年的“面向对象技术的高峰会议”（OOPSLA）上发表的一篇文章《数据抽象和层次》（Data Abstraction and Hierarchy）里提出来的，她提出：继承必须确保超类所拥有的性质在子类中仍然成立（Inheritance should ensure that any property p

面向对象设计原则-01开闭原则在软件开发中，为了提高软件系统的可维护性和可复用性，增加软件的可扩展性和灵活性，程序员要尽量根据 7 条原则来开发程序，从而提高软件开发效率、节约软件开发成本和维护成本。我们将在下面的几节中依次来介绍这 7 条原则，本节首先介绍开闭原则。文章目录面向对象设计原则-01开闭原则一、开闭原则的定义二、开闭原则的作用2.1 对软件测试的影响2.2 可以提高代码的可复用性2.3 可以提高软件的可维护性开闭原则的实现方法一、开闭原则的定义开闭原则（Open Closed Pr