读《秒懂设计模式》

第一章概述

作为有思想高度的开发者一定要培养“偷懒”意识，想方设法以最少的代码量实现最强的功能，这样才是优秀的设计。
设计模式主要研究的是“变”与“不变”，以及如何将它们分离、解耦、组装，将其中“不变”的部分沉淀下来，避免“重复造轮子”，而对于“变”的部分则可以用抽象化、多态化等方式，增强软件的兼容性、可扩展性。如果将编写代码比喻成建筑施工，那么设计模式就像是建筑设计。这就像乐高积木的设计理念一样，圆形点阵式的接口具有极强的兼容性，能够让任意组件自由拼装、组合，形成一个全新的物件。
23种三大类设计模式：并不局限于某种特定的编程语言，它是从更加宏观的思想高度上展开的一种格局观，是一套基于前人经验总结出的软件设计指导思想。

备考软考时重新理解设计模式，刷题笔记后续更新：

创建篇

第2章单例

单例模式（Singleton）是一种非常简单且容易理解的设计模式。顾名思义，单例即单一的实例，确切地讲就是指在某个系统中只存在一个实例，同时提供集中、统一的访问接口，以使系统行为保持协调一致。
“一个类仅有一个实例”。

Singleton（单例）：包含一个自己的类实例的属性，并把构造方法用private关键字隐藏起来，对外只提供getInstance()方法以获得这个单例对象。
饿汉模式
懒汉模式

1.  public class Sun {
2.  
3.      private volatile static Sun sun;
4.  
5.      private Sun(){//构造方法私有化
6.      
7.      } 
8.  
9.      public static Sun getInstance() {//华山入口
10.         if (sun == null) {//观日台入口
11.             synchronized(Sun.class){//观日者进行排队
12.                if (sun == null) {
13.                    sun = new Sun();//只有排头兵造了太阳，旭日东升
14.                }
15.             }
16.         }
17.         return sun; //……阳光普照，其余人不必再造日
18.     }
19. }

第3章原型

如果达到了质量要求，即可参照这个原型进行批量生产。原型模式达到以原型实例创建副本实例的目的即可，并不需要知道其原始类，也就是说，原型模式可以用对象创建对象，而不是用类创建对象，以此达到效率的提升。

Prototype（原型接口）：声明克隆方法，对应本例程代码中的Cloneable接口。
ConcretePrototype（原型实现）：原型接口的实现类，实现方法中调用super.clone()即可得到新克隆的对象。
Client（客户端）：客户端只需调用实现此接口的原型对象方法clone()，便可轻松地得到一个全新的实例对象。

第4章工厂方法

程序设计中的工厂类往往是对对象构造、实例化、初始化过程的封装，而工厂方法（Factory Method）则可以升华为一种设计模式，它对工厂制造方法进行接口规范化，以允许子类工厂决定具体制造哪类产品的实例，最终降低系统耦合，使系统的可维护性、可扩展性等得到提升。

Product（产品）：所有产品的顶级父类，可以是抽象类或者接口。对应本章例程中的敌人抽象类。
ConcreteProduct（子产品）：由产品类Product派生出的产品子类，可以有多个产品子类。对应本章例程中的飞机类、坦克类以及关底Boss类。
Factory（工厂接口）：定义工厂方法的工厂接口，当然也可以是抽象类，它使顶级工厂制造方法抽象化、标准统一化。
ConcreteFactory（工厂实现）：实现了工厂接口的工厂实现类，并决定工厂方法中具体返回哪种产品子类的实例。

第5章抽象工厂

抽象工厂模式（Abstract Factory）是对工厂的抽象化，而不只是制造方法。我们知道，为了满足不同用户对产品的多样化需求，工厂不会只局限于生产一类产品，但是系统如果按工厂方法那样为每种产品都增加一个新工厂又会造成工厂泛滥。所以，为了调和这种矛盾，抽象工厂模式提供了另一种思路，将各种产品分门别类，基于此来规划各种工厂的制造接口，最终确立产品制造的顶级规范，使其与具体产品彻底脱钩.

AbstractProduct1、AbstractProduct2（抽象产品1、抽象产品2）：产品系列的抽象类，图中一系产品与二系产品分别代表同一产品族的多个产品系列，对应本章例程中的初级、中级、高级兵种抽象类。
ProductA1、ProductB1、ProductA2、ProductB2（产品A1、产品B1、产品A2、产品B2）：继承自抽象产品的产品实体类，其中ProductA1与ProductB1代表A族产品与B族产品的同一产品系列，类似于本章例程中人类族与外星怪兽族的初级兵种，之后的产品实体类以此类推。
AbstractFactory（抽象工厂接口）：各族工厂的高层抽象，可以是接口或者抽象类。抽象工厂对各产品系列的制造标准进行规范化定义，但具体返回哪个族的产品由具体族工厂决定，它并不关心。
ConcreteFactoryA、ConcreteFactoryB（工厂A实现、工厂B实现）：继承自抽象工厂的各族工厂，需实现抽象工厂所定义的产品系列制造方法，可以扩展多个工厂实现。对应本章例程中的人类兵工厂与外星母巢。
Client（客户端）：产品的使用者，只关心制造出的产品系列，具体是哪个产品族由工厂决定。

第6章建造者

建造者模式（Builder）所构建的对象一定是庞大而复杂的，并且一定是按照既定的制造工序将组件组装起来的，例如计算机、汽车、建筑物等。我们通常将负责构建这些大型对象的工程师称为建造者。建造者模式又称为生成器模式，主要用于对复杂对象的构建、初始化，它可以将多个简单的组件对象按顺序一步步组装起来，最终构建成一个复杂的成品对象。与工厂系列模式不同的是，建造者模式的主要目的在于把烦琐的构建过程从不同对象中抽离出来，使其脱离并独立于产品类与工厂类，最终实现用同一套标准的制造工序能够产出不同的产品。

Product（产品）：复杂的产品类，构建过程相对复杂，需要其他组件组装而成。对应本章例程中的建筑物类。
Builder（建造者）：建造者接口，定义了构成产品的各个组件的构建标准，通常有多个步骤。对应本章例程中的施工方接口。
ConcreteBuilder（建造者实现）：具体的建造者实现类，可以有多种实现，负责产品的组装但不包含整体建造逻辑。对应本章例程中的别墅施工方类与多层公寓施工方类。
Director（指导者）：持有建造者接口引用的指导者类，指导建造者按一定的逻辑进行建造。对应本章例程中的工程总监类。

结构篇

第7章门面

无论是“门”还是“面”，指代的都是某系统的外观部分，也就是与外界接触的临界面或接口，所以门面模式常常也被翻译为“外观模式”。利用门面模式，我们可以把多个子系统“关”在门里面隐藏起来，成为一个整合在一起的大系统，来自外部的访问只需通过这道“门面”（接口）来进行，而不必再关心门面背后隐藏的子系统及其如何运转。总之，无论门面内部如何错综复杂，从门面外部看来总是一目了然，使用起来也很简单。

Facade（外观门面）：封装了多个子系统，并将它们整合起来对外提供统一的访问接口。
SubSystemA、SubSystemB、SubSystemC（子系统A、子系统B、子系统C）：隐藏于门面中的子系统，数量任意，且对外部不可见。对应本章例程中的蔬菜商类、厨师类、服务员类等。
Client（客户端）：门面系统的使用方，只访问门面提供的接口。

第8章组合

组合模式（Composite）是针对由多个节点对象（部分）组成的树形结构的对象（整体）而发展出的一种结构型设计模式，它能够使客户端在操作整体对象或者其下的每个节点对象时做出统一的响应，保证树形结构对象使用方法的一致性，使客户端不必关注对象的整体或部分，最终达到对象复杂的层次结构与客户端解耦的目的。

Component（组件接口）：所有复合节点与叶节点的高层抽象，定义出需要对组件操作的接口标准。对应本章例程中的抽象节点类，具体使用接口还是抽象类需根据具体场景而定。
Composite（复合组件）：包含多个子组件对象（可以是复合组件或叶端组件）的复合型组件，并实现组件接口中定义的操作方法。对应本章例程中作为“根节点/枝节点”的文件夹类。
Leaf（叶端组件）：不包含子组件的终端组件，同样实现组件接口中定义的操作方法。对应本章例程中作为“叶节点”的文件类。
Client（客户端）：按所需的层级关系部署相关对象并操作组件接口所定义的接口，即可遍历树结构上的所有组件。

第9章装饰器

装饰指在某物件上装点额外饰品的行为，以使其原本朴素的外表变得更加饱满、华丽，而装饰器（装饰者）就是能够化“腐朽”为神奇的利器。装饰器模式（Decorator）能够在运行时动态地为原始对象增加一些额外的功能，使其变得更加强大。从某种程度上讲，装饰器非常类似于“继承”，它们都是为了增强原始对象的功能，区别在于方式的不同，后者是在编译时（compile-time）静态地通过对原始类的继承完成，而前者则是在程序运行时（run-time）通过对原始对象动态地“包装”完成，是对类实例（对象）“装饰”的结果。

Component（组件接口）：所有被装饰组件及装饰器对应的接口标准，指定进行装饰的行为方法。对应本章例程中的展示接口Showable。ConcreteComponent（组件实现）：需要被装饰的组件，实现组件接口标准，只具备自身未被装饰的原始特性。对应本章例程中的女生类Girl。Decorator（装饰器）：装饰器的高层抽象类，同样实现组件接口标准，且包含一个被装饰的组件。ConcreteDecorator（装饰器实现）：继承自装饰器抽象类的具体子类装饰器，可以有多种实现，在被装饰组件对象的基础上为其添加新的特性。对应本章例程中的粉底类FoundationMakeup、口红类Lipstick。

第10章适配器

适配器模式（Adapter）通常也被称为转换器，顾名思义，它一定是进行适应与匹配工作的物件。当一个对象或类的接口不能匹配用户所期待的接口时，适配器就充当中间转换的角色，以达到兼容用户接口的目的，同时适配器也实现了客户端与接口的解耦，提高了组件的可复用性。

Target（目标接口）：客户端要使用的目标接口标准，对应本章例程中的三相插孔接口TriplePin。
Adapter（适配器）：实现了目标接口，负责适配（转换）被适配者的接口specificRequest()为目标接口request()，对应本章例程中的电视机专属适配器类TVAdapter。
Adaptee（被适配者）：被适配者的接口标准，目前不能兼容目标接口的问题接口，可以有多种实现类，对应本章例程中的两相插孔接口DualPin。
Client（客户端）：目标接口的使用者。

Target（目标接口）：客户端要使用的目标接口标准，对应本章例程中的三相插孔接口TriplePin。
Adapter（适配器）：继承自被适配者类且实现了目标接口，负责适配（转换）被适配者的接口specificRequest()为目标接口request()。
Adaptee（被适配者）：被适配者的类实现，目前不能兼容目标接口的问题类，对应本章例程中的电视机类TV。
Client（客户端）：目标接口的使用者。对象适配器模式与类适配器模式基本相同，二者的区别在于前者的Adaptee（被适配者）以接口形式出现并被Adapter（适配器）引用，而后者则以父类的角色出现并被Adapter（适配器）继承，所以前者更加灵活，后者则更为简便。

第11章享元

当系统存在大量的对象，并且这些对象又具有相同的内部状态时，我们就可以用享元模式共享相同的元件对象，以避免对象泛滥造成资源浪费。

Flyweight（享元接口）：所有元件的高层规范，声明与外蕴状态互动的接口标准。对应本章例程中的绘图接口Drawable。
ConcreteFlyweight（享元实现）：享元接口的元件实现类，自身维护着内蕴状态，且能接受并响应外蕴状态，可以有多个实现，一个享元对象可以被称作一个“元”。对应本章例程中的河流类River、草地类Grass、道路类Road等。
FlyweightFactory（享元工厂）：用来维护享元对象的工厂，负责对享元对象实例进行创建与管理，并对外提供获取享元对象的服务。
Client（客户端）：享元的使用者，负责维护外蕴状态。对应本章例程中的图件工厂类TileFactory。

第12章代理

代理模式（Proxy），顾名思义，有代表打理的意思。某些情况下，当客户端不能或不适合直接访问目标业务对象时，业务对象可以通过代理把自己的业务托管起来，使客户端间接地通过代理进行业务访问。如此不但能方便用户使用，还能对客户端的访问进行一定的控制。简单来说，就是代理方以业务对象的名义，代理了它的业务。

Subject（业务接口）：对业务接口标准的定义与表示，对应本章例程中的互联网访问接口Internet。
RealSubject（被代理业务）：需要被代理的实际业务类，实现了业务接口，对应本章例程中的调制解调器Modem。
Proxy（代理）：同样实现了业务接口标准，包含被代理对象的实例并对其进行管控，对外提供代理后的业务方法，对应本章例程中的路由器RouterProxy。
Client（客户端）：业务的使用者，直接使用代理业务，而非实际业务。

第13章桥接

桥接模式（Bridge）能将抽象与实现分离，使二者可以各自单独变化而不受对方约束，使用时再将它们组合起来，就像架设桥梁一样连接它们的功能，如此降低了抽象与实现这两个可变维度的耦合度，以保证系统的可扩展性。

Abstraction（抽象方）：抽象一方的高层接口，多以抽象类形式出现并持有实现方的接口引用，对应本章例程中的画笔类。
AbstractionImpl（抽象方实施）：继承自抽象方的具体子类实现，可以有多种实施并在抽象方维度上自由扩展，对应本章例程中的黑色画笔和白色画笔。
Implementor（实现方）：实现一方的接口规范，从抽象方中剥离出来成为另一个维度，独立于抽象方并不受其干扰，对应本章例程中的尺子接口。
ConcreteImplementor（实现方实施）：实现一方的具体实施类，可以有多个实施并在实现方维度上自由扩展，对应本章例程中的正方形尺子类、三角形尺子类、圆形尺子类。

行为篇

第14章模板方法

模板是对多种事物的结构、形式、行为的模式化总结，而模板方法模式（Template Method）则是对一系列类行为（方法）的模式化。我们将总结出来的行为规律固化在基类中，对具体的行为实现则进行抽象化并交给子类去完成，如此便实现了子类对基类模板的套用。

AbstractClass（抽象基类）：定义出原始操作步骤的抽象方法（primitiveOperation）以供子类实现，并作为在模板方法中被调用的一个步骤。此外还实现了不可重写的模板方法，其可将所有原始操作组织起来成为一个框架或者平台。对应本章例程中的瀑布模型项目管理类PM。ConcreteClassA、ConcreteClassB（实现类A、实现类B）：继承自抽象基类并且对所有的原始操作进行分步实现，可以有多种实现以呈现每个步骤的多样性。对应本章例程中的人力资源管理系统项目类HRProject 、API项目类APIProject。

第15章迭代器

迭代，在程序中特指对某集合中各元素逐个取用的行为。迭代器模式（Iterator）提供了一种机制来按顺序访问集合中的各元素，而不需要知道集合内部的构造。换句话讲，迭代器满足了对集合迭代的需求，并向外部提供了一种统一的迭代方式，而不必暴露集合的内部数据结构。

Aggregate（集合接口）：集合标准接口，一种具备迭代能力的指标。对应本章例程中的Iterable接口。ConcreteAggregate（集合实现）：实现集合接口Aggregate的具体集合类，可以实例化并返回一个迭代器以供外部使用。对应本章例程中的行车记录仪类DrivingRecorder。Iterator（迭代器接口）：迭代器的接口标准，定义了进行迭代操作所需的一些方法，如next()、hasNext()等。ConcreteIterator（迭代器实现）：迭代器接口Iterator的具体实现类，记录迭代状态并对外部提供所有迭代器功能的实现。Client（客户端）：集合数据的使用者，需要从集合获取迭代器再进行遍历。

第16章责任链

责任链模式（Chain of Responsibility）允许业务请求者将责任链视为一个整体并对其发起请求，而不必关心链条内部具体的业务逻辑与流程走向，也就是说，请求者不必关心具体是哪个节点起了作用，总之业务最终能得到相应的处理。在软件系统中，当一个业务需要经历一系列业务对象去处理时，我们可以把这些业务对象串联起来成为一条业务责任链，请求者可以直接通过访问业务责任链来完成业务的处理，最终实现请求者与响应者的解耦。
Handler（业务处理者）：所有业务处理节点的顶层抽象，定义了抽象业务处理方法handle()并留给子类实现，其实体方法setSuccessor()（注入继任者）则用于责任链的构建。对应本章例程中的审批人Approver。ConcreteHandler1、
ConcreteHandler2……（业务处理者实现类）：实际业务处理的实现类，可以有任意多个，每个都实现了handle()方法以处理自己职权范围内的业务，职权范围之外的事则传递给下一位继任者（另一个业务处理者）。对应本章例程中的财务专员类Staff、财务经理类Manager、财务总监类CFO。
Client（客户端）：业务申请人，只需对业务链条的第一个入口节点发起请求即可得到最终响应。

第17章策略

策略模式（Strategy）强调的是行为的灵活切换，比如一个类的多个方法有着类似的行为接口，可以将它们抽离出来作为一系列策略类，在运行时灵活对接，变更其算法策略，以适应不同的场景。

Strategy（策略接口）：定义通用的策略规范标准，包含在系统环境中并声明策略接口标准。对应本章例程中的USB接口USB。ConcreteStrategyA、ConcreteStrategyB、ConcreteStrategyC……（策略实现）：实现了策略接口的策略实现类，可以有多种不同的策略实现，但都得符合策略接口定义的规范。对应本章例程中的USB键盘类Keyboard、USB鼠标类Mouse、USB摄像头类Camera。Context（系统环境）：包含策略接口的系统环境，对外提供更换策略实现的方法setStrategy()以及执行策略的方法executeStrategy()，其本身并不关心执行的是哪种策略实现。

第18章状态

状态模式（State）构架出一套完备的事物内部状态转换机制，并将内部状态包裹起来且对外部不可见，使其行为能随其状态的改变而改变，同时简化了事物的复杂的状态变化逻辑。

State（状态接口）：定义通用的状态规范标准，其中处理请求方法handle()将系统环境Context作为参数传入。对应本章例程中的状态接口State。ConcreteStateA、ConcreteStateB、ConcreteStateC（状态实现A、状态实现B、状态实现C）：具体的状态实现类，根据系统环境用于表达系统环境Context的各个状态，它们都要符合状态接口的规范。对应本章例程中的红灯状态Red、绿灯状态Green以及黄灯状态Yellow。Context（系统环境）：系统的环境，持有状态接口的引用，以及更新状态方法setState()，对外暴露请求发起方法request()，对应本章例程中的交通灯类TrafficLight。从类结构上看，状态模式与策略模式非常类似，其不同之处在于，策略模式是将策略算法抽离出来并由外部注入，从而引发不同的系统行为，其可扩展性更好；而状态模式则将状态及其行为响应机制抽离出来，这能让系统状态与行为响应有更好的逻辑控制能力，并且实现系统状态主动式的自我转换。状态模式与策略模式的侧重点不同，所以适用于不同的场景。

第19章备忘录

备忘录模式（Memento）则可以在不破坏元对象封装性的前提下捕获其在某些时刻的内部状态，并像历史快照一样将它们保留在元对象之外，以备恢复之用。

Originator（元）：状态需要被记录的元对象类，其状态是随时可变的。既可以生成包含其内部状态的即时备忘录，也可以利用传入的备忘录恢复到对应状态。对应本章例程中的文档类Doc。Memento（备忘录）：与元对象相仿，但只需要保留元对象的状态，一个状态对应一个备忘录对象。对应本章例程中的历史快照类History。CareTaker（看护人）：历史记录的维护者，持有所有记录的历史记录，并且提供对元数据对象的恢复操作，如撤销undo()、重做redo()等，一般不提供对历史记录的修改。对应本章例程中的编辑器类Editor。

第20章中介

中介模式（Mediator）为对象构架出一个互动平台，通过减少对象间的依赖程度以达到解耦的目的。

Mediator（中介）：共事者之间通信的中介平台接口，定义与共事者的通信标准，如连接注册方法与发送消息方法等。对应本章例程中的聊天室类ChatRoom（本例以抽象类的形式定义中介接口）。ConcreteMediator（中介实现）：可以有多种实现，持有所有共事者对象的列表，并实现中介定义的通信方法。对应本章例程中的公共聊天室类PublicChatRoom、私密聊天室类PrivateChatRoom。Colleague（共事者）、ConcreteColleague（共事实现）：共事者可以有多种共事者实现。共事者持有中介对象的引用，以使其在发送消息时可以调用中介，并由它转发给其他共事者对象。对应本章例程中的用户类User。

第21章命令

命令模式（Command）能够将指令信息封装成一个对象，并将此对象作为参数发送给接收方去执行，以使命令的请求方与执行方解耦，双方只通过传递各种命令过象来完成任务。此外，命令模式还支持命令的批量执行、顺序执行以及命令的反执行等操作。

Invoker（命令请求方）：命令的请求方或发送方，持有命令接口的引用，并控制命令的执行或反向执行操作。对应本章例程中的控制器端，如键盘控制器类Keyboard。Command（命令接口）：定义命令执行的接口标准，可包括执行与反向执行操作。ConcreteCommand（命令实现）：命令接口的实现类，可以有任意多个，其执行方法中调用命令执行方所对应的执行方法。对应本章例程中的各种命令类，如开灯命令类BulbOnCommand、电视机频道上调命令类TVChannelUpCommand等。Receiver（命令执行方）：最终的命令执行方，

第22章访问者

访问者模式（Visitor）主要解决的是数据与算法的耦合问题，尤其是在数据结构比较稳定，而算法多变的情况下。为了不“污染”数据本身，访问者模式会将多种算法独立归类，并在访问数据时根据数据类型自动切换到对应的算法，实现数据的自动响应机制，并且确保算法的自由扩展。

Element（元素接口）：被访问的数据元素接口，定义一个可以接待访问者的行为标准，且所有数据封装类需实现此接口，通常作为泛型并被包含在对象容器中。对应本章例程中的接待者接口Acceptable。ConcreteElement（元素实现）：具体数据元素实现类，可以有多个实现，并且相对固定。其accept实现方法中调用访问者并将自己“this”传回。对应本章例程中的糖果类Candy、酒类Wine和水果类Fruit。ObjectContainer（对象容器）：包含所有可被访问的数据对象的容器，可以提供数据对象的迭代功能，可以是任意类型的数据结构。对应本章例程中定义为List类型的购物车。Visitor（访问者接口）：可以是接口或者抽象类，定义了一系列访问操作方法以处理所有数据元素，通常为同名的访问方法，并以数据元素类作为入参来确定哪个重载方法被调用。ConcreteVisitor（访问者实现）：访问者接口的实现类，可以有多个实现，每个访问者类都需实现所有数据元素类型的访问重载方法，对应本章例程中的各种打折方法计价类，如折扣计价访问者DiscountVisitor。Client（客户端类）：使用容器并初始化其中各类数据元素，并选择合适的访问者处理容器中的所有数据对象。

第23章观察者

观察者模式（Observer）可以针对被观察对象与观察者对象之间一对多的依赖关系建立起一种行为自动触发机制，当被观察对象状态发生变化时主动对外发起广播，以通知所有观察者做出响应。

Subject（目标主题）：被观察的目标主题的接口抽象，维护观察者对象列表，并定义注册方法register()（订阅）与通知方法notify()（发布）。对应本章例程中的商店类Shop。ConcreteSubject（主题实现）：被观察的目标主题的具体实现类，持有一个属性状态State，可以有多种实现。对应本章例程中的商店类Shop。Observer（观察者）：观察者的接口抽象，定义响应方法update()。对应本章例程中的买家类Buyer。ConcreteObserver（观察者实现）：观察者的具体实现类，可以有任意多个子类实现。实现了响应方法update()，收到通知后进行自己独特的处理。对应本章例程中的手机买家类PhoneFans、海淘买家类HandChopper。作为一种发布/订阅（publish/subscribe）式模型，观察者模式被大量应用于具有一对多关系对象结构的场景，它支持多个观察者订阅一个目标主题。一旦目标主题的状态发生变化，目标对象便主动进行广播，即刻对所有订阅者（观察者）发布全员消息通知
基于这种一对多的关系网，观察者模式以多态化（泛型化）的方式弱化了目标主题与观察者之间强耦合的依赖关系，标准化它们的消息交互接口，并让主客关系发生反转，以“单方驱动全局”模式取代“多方持续轮询”模式，使目标主题（单方）的任何状态更新都能被即刻通过广播的形式通知观察者们（多方），解决了状态同步知悉的效率问题。

第24章解释器

解释器模式（Interpreter）会针对某种语言并基于其语法特征创建一系列的表达式类（包括终极表达式与非终极表达式），利用树结构模式将表达式对象组装起来，最终将其翻译成计算机能够识别并执行的语义树。

AbstractExpression（抽象表达式）：定义解释器的标准接口interpret()，所有终极表达式类与非终极表达式类均需实现此接口。对应本章例程中的表达式接口Expression。
TerminalExpression（终极表达式）：抽象表达式接口的实现类，具有原子性、不可拆分性的表达式。对应本章例程中的鼠标移动表达式Move、鼠标左键按下表达式LeftKeyDown、鼠标左键松开表达式LeftKeyUp、延迟表达式Delay。
NonTerminalExpression（非终极表达式）：抽象表达式接口的实现类，包含一个或多个表达式接口引用，所以它所包含的子表达式可以是非终极表达式，也可以是终极表达式。对应本章例程中的左键单击表达式LeftKeyClick、循环表达式Repetition、表达式序列Sequence。
Context（上下文）：需要被解释的语言类，它包含符合解释器语法规则的具体语言。对应本例程中的滑鼠精灵脚本MouseScript。
Client（客户端）：根据语言的语法结构生成对应的表达式语法树，然后调用根表达式的解释方法得到结果。

原则

待续～