1. 简介
1.1. 设计模式的定义
设计模式(Design Pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结，使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。
1.2. 设计模式的基本要素
- 模式名称(Pattern name)
- 问题(Problem)
- 解决方案(Solution)
- 效果(Consequences)
1.3. GoF设计模式简介
| 范围\目的 | 创建型模式 | 结构性模式 | 行为型模式 |
|---|---|---|---|
| 类模式 | 工厂方法模式 | （类）适配器模式 | 解释器模式 |
| 模板方法模式 | |||
| 对象模式 | 抽象工厂模式 | （对象）适配器模式 | 职责链模式 |
| 建造者 | 桥接模式 | 命令模式 | |
| 原型模式 | 组合模式 | 迭代器模式 | |
| 单例模式 | 装饰模式 | 中介者模式 | |
| 外观模式 | 备忘录模式 | ||
| 享元模式 | 观察者模式 | ||
| 代理模式 | 状态模式 | ||
| 策略模式 | |||
| 访问者模式 |
参考: 《设计模式:可复用面向对象软件的基础》
2. 统一建模语言基础知识
2.1. UML简介
统一建模语言(Unified Modeling Language，UML)是一种可视化的标准建模语言，它是一种分析和设计语言，通过UML可以构造软件系统的蓝图。
2.1.1. UML 的诞生
- 在一个现代化的工程中，人们要相互沟通和合作，就必须使用标准的工业化设计语言，用这些语言来对待开发的产品进行建模。
- 建模过程把复杂的问题分解成为易于理解的小问题，以达到问题的求解。
- 建模是开发优秀软件的所有活动中核心部分之一，其目的是把所要设计的结构和系统的行为联系起来，并对系统的结构进行可视化控制。
2.1.2. UML 的结构
1. 视图(View)
- 用户视图：以用户的观点表示系统的目标，它是所有视图的核心，该视图描述系统的需求。
- 结构视图：表示系统的静态行为，描述系统的静态元素，如包、类与对象，以及它们之间的关系。
- 行为视图：表示系统的动态行为，描述系统的组成元素如对象在系统运行时的交互关系。
- 实现视图：表示系统中逻辑元素的分布，描述系统中物理文件以及它们之间的关系。
- 环境视图：表示系统中物理元素的分布，描述系统中硬件设备以及它们之间的关系。
2. 图(Diagram)
- 用例图(Use Case Diagram):又称为用况图，对应于用户视图。在用例图中，使用用例来表示系统的功能需求，用例图用于表示多个外部执行者与系统用例之间以及用例与用例之间的关系。用例图与用例说明文档(Use Case Specification)是常用的需求建模工具，也称之为用例建模。
- 类图(Class Diagram)：对应于结构视图。类图使用类来描述系统的静态结构，类图包含类和它们之间的关系，它描述系统内所声明的类，但它没有描述系统运行时类的行为。
- 对象图(Object Diagram)：对应于结构视图。对象图是类图在某一时刻的一个实例，用于表示类的对象实例之间的关系。
- 包图(Package Diagram)：UML2.0新增图，对应于结构视图。包图用于描述包与包之间的关系，包是一种把元素组织到一起的通用机制，如可以将多个类组织成一个包。
- 组合结构图(Composite Structure Diagram)：UML2.0新增图，对应于结构视图。组合结构图将每一个类放在一个整体中，从类的内部结构来审视一个类。组合结构图可用于表示一个类的内部结构，用于描述一些包含复杂成员或内部类的类结构。
- 状态图(State Diagram)：对应于行为视图。状态图用来描述一个特定对象的所有可能状态及其引起状态转移的事件。一个状态图包括一系列对象的状态及状态之间的转换。
- 活动图(Activity Diagram)：对应于行为视图。活动图用来表示系统中各种活动的次序，它的应用非常广泛，既可用来描述用例的工作流程，也可以用来描述类中某个方法的操作行为。
- 顺序图(Sequence Diagram)：又称为时序图或序列图，对应于行为视图。顺序图用于表示对象之间的交互，重点表示对象之间发送消息的时间顺序。
- 通信图(Communication Diagram)：在UML1.x中称为协作图，对应于行为视图。通信图展示了一组对象、这些对象间的连接以及它们之间收发的消息。它与顺序图是同构图，也就是它们包含了相同的信息，只是表达方式不同而已，通信图与顺序图可以相互转换。
- 定时图(Timing Diagram)：UML2.0新增图，对应于行为视图。定时图采用一种带数字刻度的时间轴来精确地描述消息的顺序，而不是像顺序图那样只是指定消息的相对顺序，而且它还允许可视化地表示每条生命线的状态变化，当需要对实时事件进行定义时，定时图可以很好地满足要求。
- 交互概览图(Interaction Overview Diagram)：UML2.0新增图，对应于行为视图。交互概览图是交互图与活动图的混合物，可以把交互概览图理解为细化的活动图，在其中的活动都通过一些小型的顺序图来表示；也可以将其理解为利用标明控制流的活动图分解过的顺序图。
- 组件图(Component Diagram)：又称为构件图，对应于实现视图。组件图用于描述每个功能所在的组件位置以及它们之间的关系。
- 部署图(Deployment Diagram)：又称为实施图，对应于环境视图。部署图用于描述软件中各个组件驻留的硬件位置以及这些硬件之间的交互关系。
在 UML 中，顺序图、通信图、定时图和交互概览图又统称交互图(Interactive Diagram)，交互图是表示各对象如何依据某种行为进行协作的模型，通常可以使用一个交互图来表示和说明一个用例的行为。
3. 模型元素(Model element)
- 在UML中，模型元素包括事物以及事物与事物之间的联系。事物是UML的重要组成部分，它代表任何可以定义的东西。事物之间的关系把事物联系在一起，组成有意义的结构模型。每一个模型元素都有一个与之相对应的图形元素。
- 同一个模型元素可以在不同的UML图中使用，但是，无论在哪个图中，同一个模型元素都保持相同的意义和符号。
4. 通用机制(General mechanism)
- UML提供的通用机制为模型元素提供额外的注释、修饰和语义等，主要包括规格说明、修饰、公共分类和扩展机制四种。扩展机制允许用户对UML进行扩展，以便一个特定的方法、过程、组织或用户来使用。
2.1.3. UML 的特点
- 工程化
- 规范化
- 可视化
- 系统化
- 文档化
- 智能化
2.2. 类图
2.2.1. 类与类图
- 类(Class)封装了数据和行为，是面向对象的重要组成部分，它是具有相同属性、操作、关系的对象集合的总称。
- 在系统中，每个类具有一定的职责，职责指的是类所担任的任务，即类要完成什么样的功能，要承担什么样的义务。一个类可以有多种职责，设计得好的类一般只有一种职责，在定义类的时候，将类的职责分解成为类的属性和操作（即方法）。
- 类的属性即类的数据职责，类的操作即类的行为职责。
- 在UML类图中，类一般由三部分组成：
- 类名：每个类都必须有一个名字，类名是一个字符串。
- 属性(Attributes)：属性是指类的性质，即类的成员变量。类可以有任意多个属性，也可以没有属性。
- 操作(Operations)：操作是类的任意一个实例对象都可以使用的行为，操作是类的成员方法。
2.2.2. 类之间的关系
2.2.2.1. 关联关系
- 关联关系(Association)是类与类之间最常用的一种关系，它是一种结构化关系，用于表示一类对象与另一类对象之间有联系。
- 在UML类图中，用实线连接有关联的对象所对应的类，在使用Java、C#和C++等编程语言实现关联关系时，通常将一个类的对象作为另一个类的属性。
- 在使用类图表示关联关系时可以在关联线上标注角色名。
1. 双向关联 2. 单向关联 3. 自关联 4. 重数性关联： 重数性关联关系又称为多重性关联关系(Multiplicity)，表示一个类的对象与另一个类的对象连接的个数。在UML中多重性关系可以直接在关联直线上增加一个数字表示与之对应的另一个类的对象的个数。 5. 聚合关系： 聚合关系(Aggregation)表示一个整体与部分的关系。通常在定义一个整体类后，再去分析这个整体类的组成结构，从而找出一些成员类，该整体类和成员类之间就形成了聚合关系。 在聚合关系中，成员类是整体类的一部分，即成员对象是整体对象的一部分，但是成员对象可以脱离整体对象独立存在。在UML中，聚合关系用带空心菱形的直线表示。 6. 组合关系： 组合关系(Composition)也表示类之间整体和部分的关系，但是组合关系中部分和整体具有统一的生存期。一旦整体对象不存在，部分对象也将不存在，部分对象与整体对象之间具有同生共死的关系。 在组合关系中，成员类是整体类的一部分，而且整体类可以控制成员类的生命周期，即成员类的存在依赖于整体类。在UML中，组合关系用带实心菱形的直线表示。 7. 依赖关系： 依赖关系(Dependency)是一种使用关系，特定事物的改变有可能会影响到使用该事物的其他事物，在需要表示一个事物使用另一个事物时使用依赖关系。大多数情况下，依赖关系体现在某个类的方法使用另一个类的对象作为参数。 在UML中，依赖关系用带箭头的虚线表示，由依赖的一方指向被依赖的一方。 8. 范化关系： 泛化关系(Generalization)也就是继承关系，也称为“is-a-kind-of”关系，泛化关系用于描述父类与子类之间的关系，父类又称作基类或超类，子类又称作派生类。在UML中，泛化关系用带空心三角形的直线来表示。 在代码实现时，使用面向对象的继承机制来实现泛化关系，如在Java语言中使用extends关键字、在C++/C#中使用冒号“：”来实现。 9. 接口与实现关系： 接口之间也可以有与类之间关系类似的继承关系和依赖关系，但是接口和类之间还存在一种实现关系(Realization)，在这种关系中，类实现了接口，类中的操作实现了接口中所声明的操作。在UML中，类与接口之间的实现关系用带空心三角形的虚线来表示。
2.2.2.2. 实例说明：
某基于Java语言的C/S软件需要提供注册功能，该功能简要描述如下： 用户通过注册界面(RegisterForm)输入个人信息，用户点击“注册”按钮后将输入的信息通过一个封装用户输入数据的对象(UserDTO)传递给操作数据库的数据 访问类(DAO)，为了提高系统的扩展性，针对不同的数据库可能需要提供不同的数据访问类，因此提供了数据访问类接口，如IUserDAO，每一个具体数据访问 类都是某一个数据访问类接口的实现类，如OracleUserDAO就是一个专门用于访问Oracle数据库的数据访问类。 根据以上描述绘制类图。为了简化类图，个人信息仅包括账号(userAccount)和密码(userPassword)，且界面类无须涉及界面细节元素。
2.2.2.3. 注释(Comment)
2.3. 顺序图
顺序图是最常用的系统动态建模工具之一，也是使用频率最高的交互图。它用于表示对象之间的动态交互，而且以图形化的方式描述了对象间消息传递的时间顺序。
2.3.1. 定义
- 顺序图(Sequence Diagram)是一种强调对象间消息传递次序的交互图，又称为时序图或序列图。
- 顺序图以图形化的方式描述了在一个用例或操作的执行过程中对象如何通过消息相互交互，说明了消息如何在对象之间被发送和接收以及发送的顺序。顺序图允许直观地表示出对象的生存期，在生存期内，对象可以对输入消息做出响应，还可以发送信息。
- 在软件系统建模中，顺序图的使用很灵活，通常包括如下两种顺序图：
- 需求分析阶段的顺序图：主要用于描述用例中对象之间的交互，可以使用自然语言来绘制，用于细化需求，它从业务的角度进行建模，用描述性的文字叙述消息的内容。
- 系统设计阶段的顺序图：确切表示系统设计中对象之间的交互，考虑到具体的系统实现，对象之间通过方法调用传递消息。
2.3.2. 顺序图组成元素
在UML中，顺序图将交互关系表示为一个二维图，纵向是时间轴，时间沿竖线向下延伸；横向轴表示了在交互过程中的独立对象，对象的活动用生命线表示。顺 序图由执行者(Actor)、生命线(Lifeline)、对象(Object)、激活框(Activation)和消息(Message)等元素组成。
2.3.3. 实例说明
某基于Java EE的B/S系统需要提供登录功能，该功能简要描述如下：用户打开登录界面login.jsp输入数据，向系统提交请求，系统通过Servlet获取请求数据， 将数据传递给业务对象，业务对象接收数据后再将数据传递给数据访问对象，数据访问对象对数据库进行操作，查询用户信息，再返回查询结果。 根据以上描述绘制顺序图。
2.4. 状态图
状态图用于描述对象的各种状态以及状态之间的转换。
2.4.1. 定义
- 状态图(Statechart Diagram)用来描述一个特定对象的所有可能状态及其引起状态转移的事件。
- 一个状态图包括一系列的状态及状态之间的转移。
- 大多数面向对象技术都使用状态图来描述一个对象在其生命周期中的行为，对象从产生到结束，可以处于一系列不同的状态。
- 状态影响对象的行为，当这些状态的数目有限时，就可以用状态图来建模对象的行为，状态图显示了单个类的生命周期，在不同状态下对象可能具有不同的行为。
- 状态图适用于描述在不同用例之间的对象行为，但并不适合于描述包括若干协作的对象行为，因为一个状态图只能用于描述一个类的对象状态，如果涉及到多个不同类的对象，则需要使用活动图。
2.4.2. 状态图组成元素
- 状态(State)：又称为中间状态，用圆角矩形框表示，在一个状态图中可有多个状态，每个状态包含两格：上格放置状态名称，下格说明处于该状态时对象可以进行的活动(Action)。
- 初始状态(Initial State)：又称为初态，用一个黑色的实心圆圈表示，在一个状态图中只能够有一个初始状态。
- 结束状态(Final State)：又称为终止状态或终态，用一个实心圆外加一个圆圈表示，在一个状态图中可能有多个结束状态。
- 转移(Transition)：用从一个状态到另一个状态之间的连线和箭头说明状态的转移情况，并用文字说明引发这个状态变化的相应事件是什么。事件有可能在特定的条件下发生，在UML中这样的条件称为守护条件(Guard Condition)，发生事件时的处理也称为动作(Action)。状态之间的转移可带有标注，由三部分组成（每一部分都可省略），其语法为：事件名 [条件] / 动作名。
- 在一个状态图中，一个状态也可以被细分为多个子状态，包含多个子状态的状态称为复合状态。
2.4.3. 实例说明
某信用卡系统账户具有使用状态和冻结状态，其中使用状态又包括正常状态和透支状态两种子状态。如果账户余额小于零则进入透支状态，透支状态时既可以存 款又可以取款，但是透支金额不能超过5000元；如果余额大于零则进入正常状态，正常状态时既可以存款又可以取款；如果连续透支100天，则进入冻结状态， 冻结状态下既不能存款又不能取款，必须要求银行工作人员解冻。用户可以在使用状态或冻结状态下请求注销账户。根据上述要求，绘制账户类的状态图。
2.5. 小结
- UML是一种分析设计语言，即一种建模语言。UML是由图形符号表达的建模语言，其结构主要包括视图、图、模型元素和通用机制四部分。
- UML包括5种视图，分别是用户视图、结构视图、行为视图、实现视图和环境视图。
- 在UML2.0中，提供了13种图，分别是用例图、类图、对象图、包图、组合结构图、状态图、活动图、顺序图、通信图、定时图、交互概览图、组件图和部署图。
- UML已成为用于描绘软件蓝图的标准语言，它可用于对软件密集型系统进行建模，其主要特点包括：工程化、规范化、可视化、系统化、文档化和智能化。
- 类图使用出现在系统中的不同类来描述系统的静态结构，类图用来描述不同的类和它们的关系。
- 在UML中，类之间的关系包括关联关系、依赖关系、泛化关系和实现关系，其中关联关系又包括双向关联、单向关联、自关联、重数性关联、聚合关系和组合关系。
- 顺序图是一种强调对象间消息传递次序的交互图，又称为时序图或序列图。顺序图以图形化的方式描述了在一个用例或操作的执行过程中对象如何通过消息相互交互，说明了消息如何在对象之间被发送和接收以及发送的顺序。顺序图允许直观地表示出对象的生存期，在生存期内，对象可以对输入消息做出响应，还可以发送信息。
- 顺序图由执行者、生命线、对象、激活框、消息和交互片段等元素组成。
- 状态图用来描述一个特定对象的所有可能状态及其引起状态转移的事件。我们通常用状态图来描述单个对象的行为，它确定了由事件序列引出的状态序列，一个状态图包括一系列的状态及状态之间的转移。
- 状态图由状态、初始状态、结束状态和转移等元素组成。在一个状态图中，一个状态也可以被细分为多个子状态，包含多个子状态的状态称为复合状态。
3. 面向对象设计原则
3.1. 面向对象设计原则概述
3.1.1. 软件的可维护性和可复用性
1. 知名软件大师Robert C.Martin认为一个可维护性(Maintainability) 较低的软件设计，通常由于如下4个原因造成：
- 过于僵硬(Rigidity)
- 过于脆弱(Fragility)
- 复用率低(Immobility)
- 黏度过高(Viscosity)
2. 软件工程和建模大师Peter Coad认为，一个好的系统设计应该具备如下三个性质：
- 可扩展性(Extensibility)
- 灵活性(Flexibility)
- 可插入性(Pluggability)
3. 重构(Refactoring)是在不改变软件现有功能的基础上，通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理， 提高软件的扩展性和维护性
3.1.2. 面向对象设计原则简介
常用的面向对象设计原则包括7个，这些原则并不是孤立存在的，它们相互依赖，相互补充。
| 设计原则名称 | 设计原则简介 | 重要性 |
|---|---|---|
| 单一职责原则 | 类的职责要单一，不能将太多的职责放在一个类中 | ★★★★☆ |
| (Single Responsibility Principle, SRP) | ||
| 开闭原则 | 软件实体对扩展是开放的，但对修改是关闭的，即在不修改一个 | ★★★★★ |
| (Open-Closed Principle, OCP) | 软件实体的基础上去扩展其功能 | |
| 里氏代换原则 | 在软件系统中，一个可以接受基类对象的地方必然可以接受一个 | ★★★★☆ |
| (Liskov Substitution Principle, LSP) | 个子类对象 | |
| 依赖倒转原则 | 要针对抽象层编程，而不要针对具体类编程 | ★★★★★ |
| (Dependency Inversion Principle, DIP) | ||
| 接口隔离原则 | 使用多个专门的接口来取代一个统一的接口 | ★★☆☆☆ |
| (Interface Segregation Principle, ISP) | ||
| 合成复用原则 | 在系统中应该尽量多使用组合和聚合关联关系，尽量少使用甚至 | ★★★★☆ |
| (Composite Reuse Principle, CRP) | 不使用继承关系 | |
| 迪米特法则 | 一个软件实体对其他实体的引用越少越好，或者说如果两个类不 | ★★★☆☆ |
| (Law of Demeter, LoD) | 必彼此直接通信，那么这两个类就不应当发生直接的相互作用， | |
| 而是通过引入一个第三者发生间接交互 |
3.2. 单一职责原则
3.2.1. 定义
一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。 Every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class.
就一个类而言，应该仅有一个引起它变化的原因。 There should never be more than one reason for a class to change.
3.2.2. 分析
一个类（或者大到模块，小到方法）承担的职责越多，它被复用的可能性越小
类的职责主要包括两个方面：数据职责和行为职责，数据职责通过其属性来体现，而行为职责通过其方法来体现。
单一职责原则是实现高内聚、低耦合的指导方针，在很多代码重构手法中都能找到它的存在，它是最简单但又最难运用的原则，需要设计人员 发现类的不同职责并将其分离，而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。
3.2.3. 实例
3.3. 开闭原则
3.3.1. 定义
一个软件实体应当对扩展开放，对修改关闭。也就是说在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展，即实现 在不修改源代码的情况下改变这个模块的行为。 Software entities should be open for extension, but closed for modification.
3.3.2. 分析
软件实体可以指一个软件模块、一个由多个类组成的局部结构或一个独立的类。
抽象化是开闭原则的关键。 开闭原则还可以通过一个更加具体的“对可变性封装原则”来描述，对可变性封装原则(Principle of Encapsulation of Variation, EVP) 要求找到系统的可变因素并将其封装起来。
3.3.3. 实例
某图形界面系统提供了各种不同形状的按钮，客户端代码可针对这些按钮进行编程，用户可能会改变需求要求使用不同的按钮。
3.4. 里氏代换原则
3.4.1. 定义
如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有变化， 那么类型S是类型T的子类型。 If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.
所有引用基类（父类）的地方必须能透明地使用其子类的对象。 Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
3.4.2. 分析
在软件中如果能够使用基类对象，那么一定能够使用其子类对象。把基类都替换成它的子类，程序将不会产生任何错误和异常，反过来则 不成立，如果一个软件实体使用的是一个子类的话，那么它不一定能够使用基类。
在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。
3.4.3. 实例
3.5. 依赖倒转原则
3.5.1. 定义
高层模块不应该依赖低层模块，它们都应该依赖抽象。抽象不应该依赖于细节，细节应该依赖于抽象。 High level modules should not depend upon low level modules, both should depend upon abstractions. Abstractions should not depend upon details, details should depend upon abstractions.
要针对接口编程，不要针对实现编程。 Program to an interface, not an implementation.
3.5.2. 分析
1. 代码要依赖于抽象的类，而不要依赖于具体的类；要针对接口或抽象类编程，而不是针对具体类编程。
2. 如果说开闭原则是面向对象设计的目标的话，那么依赖倒转原则就是面向对象设计的主要手段。
3.类之间的耦合 > 零耦合关系 > 具体耦合关系 > 抽象耦合关系 依赖倒转原则要求客户端依赖于抽象耦合，以抽象方式耦合是依赖倒转原则的关键。
3. 依赖注入 构造注入(Constructor Injection)：通过构造函数注入实例变量。 设值注入(Setter Injection)：通过Setter方法注入实例变量。 接口注入(Interface Injection)：通过接口方法注入实例变量。
3.5.3. 实例
某系统提供一个数据转换模块，可以将来自不同数据源的数据转换成多种格式，如可以转换来自数据库的数据(DatabaseSource)、 也可以转换来自文本文件的数据(TextSource)，转换后的格式可以是XML文件(XMLTransformer)、也可以是XLS文件 (XLSTransformer)等。
由于需求的变化，该系统可能需要增加新的数据源或者新的文件格式，每增加一个新的类型的数据源或者新的类型的文件格式， 客户类MainClass都需要修改源代码，以便使用新的类，但违背了开闭原则。现使用依赖倒转原则对其进行重构。
3.6. 接口隔离原则
3.6.1. 定义
3.6.2. 分析
3.6.3. 实例
3.7. 合成复用原则
3.7.1. 定义
3.7.2. 分析
3.7.3. 实例
3.8. 迪米特法则
3.8.1. 定义
3.8.2. 分析
3.8.3. 实例
4. 创建型模式
4.1. 介绍
创建型模式(Creational Pattern)对类的实例化过程进行了抽象，能够将软件模块中对象的创建和对象的使用分离。为了使软件的结构更加清晰， 外界对于这些对象只需要知道它们共同的接口，而不清楚其具体的实现细节，使整个系统的设计更加符合单一职责原则。
创建型模式在创建什么(What)，由谁创建(Who)，何时创建(When)等方面都为软件设计者提供了尽可能大的灵活性。创建型模式隐藏了类的实例 的创建细节，通过隐藏对象如何被创建和组合在一起达到使整个系统独立的目的。
4.2. 创建型模式有哪些？
简单工厂模式（Simple Factory） 重要程度：4 （5为满分） 工厂方法模式（Factory Method） 重要程度：5 抽象工厂模式（Abstract Factory） 重要程度：5 建造者模式（Builder） 重要程度：2 原型模式（Prototype） 重要程度：3 单例模式（Singleton） 重要程度：4
4.3. 简单工厂模式
4.3.1. 模式定义
简单工厂模式(Simple Factory Pattern)：又称为静态工厂方法(Static Factory Method)模式，它属于类创建型模式。在简单工厂模式中，可以根据参数的不同返回 不同类的实例。简单工厂模式专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。
4.3.2. 举例说明
/** * 简单工厂模式（Simple Factory Pattern）应用举例：多种支付方式。 */ // 1.抽象支付方法类 public abstract class AbstractPay{ public abstract void pay(); } // 2.支付方式类 // 现金支付类 public class CashPay extends AbstractPay{ public void pay(){ // 现金支付处理代码 } } // 信用卡支付类 public class CreditcardPay extends AbstractPay{ public void pay(){ // 信用卡支付处理代码 } } // 3.支付方式工厂类 public class PayMethodFactory{ public static AbstractPay getPayMethod(String type){ if (type.equalsIgnoreCase("cash")) { return new CashPay(); // 根据参数创建具体产品 }else if (type.equalsIgnoreCase("creditcard")) { return new CreditcardPay(); // 根据参数创建具体产品 }else{ // ... } } }
4.3.3. 模式分析
1.意义： 1)将对象的创建和对象本身业务处理分离可以降低系统的耦合度，使得两者修改起来都相对容易。 2)使用简单工厂模式后，系统中类的个数增加，每一种支付处理方式都封装到单独的模式中，而且工厂类中只有简单的判断逻辑代码，不需要关心具体的业务处理过程，满足“单一职责原则”。# 3)在调用工厂类的工厂方法时，由于工厂方法是静态方法，使用起来很方便，可通过类名直接调用，而且只需要传入一个简单的参数即可，在实际开发中，还可以在调用时将所传入的参数保存在XML等格式的配置文件中，修改参数时无须修改任何源代码。 简单工厂模式最大的问题在于工厂类的职责相对过重，增加新的产品需要修改工厂类的判断逻辑，这一点与开闭原则是相违背的。 简单工厂模式的要点在于：当你需要什么，只需要传入一个正确的参数，就可以获取你所需要的对象，而无须知道其创建细节。
4.3.4. 模式应用
1. JDK类库中广泛使用了简单工厂模式，如工具类java.text.DateFormat，它用于格式化一个本地日期或者时间。 public final static DateFormat getDateInstance(); public final static DateFormat getDateInstance(int style); public final static DateFormat getDateInstance(int style,Locale locale); 2. Java加密技术 获取不同加密算法的密钥生成器: KeyGenerator keyGen=KeyGenerator.getInstance("DESede"); 创建密码器: Cipher cp=Cipher.getInstance("DESede");