敏捷软件开发 第十三章~第十七章
这几章主要讲了几个设计模式,分别是:
Command (命令模式)
Active Object (主动对象模式)
Template Method (模板方法模式)
Strategy (策略模式)
Facade(外观模式)
Mediator (中介者模式)
Singleton (单例模式)
Monostate (单态模式)
Null Object (空对象模式)
下面分别就我做了了解的模式进行介绍,分别是:
Command (命令模式)
Template Method (模板方法模式)
Strategy (策略模式)
Facade(外观模式)
Singleton (单例模式)
Command (命令模式)
我认为命令模式的主要作用在于两点:
1、解耦命令调用者(Invoker)和命令执行者(Receiver),让他们独立的变化
2、对需要重复使用的功能进行封装,以便实现一次书写,多次使用
命令调用者(Invoker)使用 Command 接口来调用 Receiver 来处理任务,而 Receiver 通过被 Command 接口的实现类调用,来完成任务
这样的话,Invoker 和 Receiver 可以独立地变化
且当有日志等系统性的功能需要实现的时候,可以直接在 Invoker 中加入相关代码,而不用每次调用命令的时候,都在 Client 中实现同样的代码
整个调用链:Client → Invoker(命令调用者,也是封装变化的地方) → Command ← ConcreteCommand(实现 Command 接口) ← Receiver
Template Method (模板方法模式)
我认为的要点:
1、使用抽象类封装算法(这里的算法指控制整个流程的代码)
2、将流程中每一步,交由具体的类去实现
调用链
abstract base class ← implement class
abstract base class 中定义了包含算法的实际(非抽象)方法,定义了流程中每一步的抽象方法
implement class 继承 abstract base class,实现了其中的抽象方法
这样,算法就可以被复用了
但是,有个缺点,那就是耦合性较高,要使用算法的话,必须继承抽象基类(abstract base class)
于是,就有了策略模式,对其进行改进
Strategy (策略模式)
使用模板方法模式时,为了实现算法的复用,必须要继承包含算法的抽象基类,耦合性较高
对此,策略模式使用了另一种方式实现算法的复用
即,将抽象的流程方法从抽象基类(abstract base class)中分离出去,分离到一个接口(interface)中
这样,抽象基类,就变成了只包含非抽象方法的非抽象基类(base class),而对于要复用算法的类而言,它只需要实现定义了那些抽象流程方法的接口即可
在使用时,客户端伪代码如下:
// 创建基类实例(利用带参的构造方法传入具体的实现类)
// 使用基类实例,调用包含算法代码的方法
这样,由于使用了接口隔离了算法和具体的实现代码
要使用某个算法的时候,就不用继承包含该算法的类了
而且,不仅算法可以复用,连具体的实现代码都可以复用(同类型的算法,使用同一份实现代码),即,在客户端代码中,创建的基类可以变,传入的实现类也可以变
Template Method (模板方法模式) 和 Strategy (策略模式) 的比较
以下是我个人的一些联想和思考,不一定正确
模板方法模式不符合 DIP,而策略模式符合 DIP
Facade(外观模式)
个人理解:
将一套复杂的逻辑,封装起来,只将需要关注的部分暴露给调用者
站在调用者的角度,那一套复杂的逻辑是不可见(也是不需要看见)的
调用者通过调用封装的那一个接口去调用它背后的一套复杂逻辑
感觉 JDBC 就是使用了这一模式,但是查了一下,发现 JDBC 主要使用的是桥接模式,现在对这个模式不了解,以后再查查
Singleton (单例模式)
类和示例通常是一对多的关系
但是
对于某些特殊的类,它们只允许有一个实例,比如,工厂对象、管理器对象
如果这些类有多个实例,会引发严重的逻辑错误
此时,就需要用到单例模式
实现单例模式有三个要点:
1、私有化构造函数
2、一个私有的私立变量
3、公开、静态的得到实例的方法(getInstance)
这样,外部就只能通过 getInstance 方法才能获取实例那个唯一的实例