21/12/6 软件体系结构复习-设计模式

策略模式

基本原则:责任分离+高内聚低耦合

各部分组成及说明

1. strategy:定义了一个共同的接口,所有的具体算法类实现这个接口.换进该类context调用这个接口调用具体的算法类
2. ConcreteStragety 封装了具体的算法,实现统一个几口
3. Context 环境类.用于配置一个具体的算法策略对象,维持一个策略接口类型的参考,并且可以定义一个让接口Strategy的具体对象访问的接口(可省略)

使用策略模式的情况

1. 当有多个行为上不同但是相关的类存在.
2. 当某个算法使用用户不该知道的数据时,使用策略模式可以将算法实现细节隐藏起来.
3. 当一个类有多种行为,这些行为以大块的条件语句实现时,可以将这些条件块移入他们自己的Strategy类中

使用策略模式的出发点

1. 将一组相关的算法封装为各个策略分支,从而将策略分支相关的代码隐藏起来
2. 提升程序的可拓展性

优点

1. 得到一系列可服用的算法,这些算法继承一个共同的抽象类,因此公有的功能可以放到超类中
2. 将不同算法封装在不同的策略子类中,使逻辑更加清晰,各个算法可以独立地变化
3. 是功能改变或拓展变得更容易

创建型模式

工厂模式

简单工厂

各组成部分的功能

1. Creater 核心,包含应用程序锁需要的业务逻辑.同时负责委托工厂生产对象
2. Product 接口/抽象类 是具体子类的超类/接口
3. ConcreteProduct 实现Product接口/继承Product抽象类

优点

1. 工厂方法包含从一个类的结构中选择初始类的业务逻辑
2. 客户类不直接创建产品类的对象,值作为对象的消费者
3. 实现了责任分离
4. 如果有新产品子类加入,不必修改客户类(前提是客户类不用新产品)
5. 因为1,所以客户类不需要繁杂的逻辑判断

缺点

1. 增加产品类时,要修改工厂类
2. 因为工厂类的工厂方法是静态的,所以工厂类中的方法不能被继承,因此只能承载一个单独的类群,而不是一个有多层结构的类

为了解决简单工厂的缺点—工厂方法

工厂方法

核心思想:将简单工厂中单一的工厂类改写成一个层次类

类图解释

Creater: 接口,含有一个factory方法,然后可以用和产品类相同的结构产生创建者类结构,其中包含CreaterA和CreaterB

CreaterA/B:负责创建对应的ProductA和ProductB的对象

和简单工厂的相同之处

1. 方法模式一样,工厂方法也返回一个属于父类Product类型的对象,客户不必知道返回对象的具体类型

和简单工厂的区别

1. 中心不同.工厂方法的中心是抽象工厂类/接口,而简单工厂方法的中心是一个实的工厂类
   在简单工厂的工厂方法是静态的,而工厂方法是动态的
2. 简单工厂方法不支持开闭原则.而工厂方法支持.
   简单工厂增加产品类:在工厂类中也应增加条件语句
   工厂方法增加产品类:在Product类的结构体重增加一个实体,在工厂类层次结构体中增加一个相应的能产生该新产品对象的实类
3. 工厂方法工厂类不必包含创建对象的逻辑判断

使用工厂方法的情况

1. 创建某些类的对象的逻辑比较复杂,并且有很多条件分支
2. 一个类不能准确预知它要创建一个层次类中哪个子类的对象
3. 一个类使用子类决定要创建的对象
4. 需要封装创建类的对象的逻辑,使这些逻辑局部化

抽象工厂模式

类图

抽象工厂模式中包含

1. 一系列互相有关联的产品类,(有相同的结构)
2. 一系列实的工厂类,实现由抽象工厂提供的接口.他们各自生产一组相关的产品类对象

当客户对象要从一个相关的产品组中创建一个对象,而没有必要知道到底创建哪个对象时使用抽象工厂

抽象工厂方法不符合开闭原则–增加一个新产品层次类,则必须在每个工厂实类中增加方法

装饰者模式

提供一个比继承更加灵活的方案

类图

访问者模式

解决问题–对一个已经完成设计与diamante编写的类的层次结构进行功能修改或增加新功能

类图解释

1. VIsitor: 为每个element的类声明了一个访问操作
2. concreteVisitor: 实现Visitor声明的运算
3. Element: 定义了一些基本的方法,包含提供基本数据的方法.
   重要的是,它的子类必须定义一个接收者方法,为被访问者对象和访问者对象之间提供接口
4. ConcreteElement :具体的Element的子类
5. ObjectStructure 提供一个高层接口,允许访问者访问Element的子类.,提供一个访问列表

使用访问者模式的情况

1. 当一个对象的结构中,包含有多种类型的具有不同接口的对象,且用户要在这些对象上进行依赖于具体的类的运算
2. 当有多个不同的并且互不相关的运算将作用域这些对象上,且用户不希望这些运算混淆这些类时
3. 当对象的数据类型很少改变,但需要经常改变操作或增加新操作的情况下.

状态模式

将不同状态下的行为封装在不同的类中,每个类代表一个状态

使用场景:

当一个类依赖于状态,那么程序员在描述该对象的类中通常会使用很多条件语句,
这时,使用状态模式可以有效消除条件语句并使得状态转换非常清楚

GANG OF FOUR的定义:

允许一个对象在其内部状态改变时,改变其行为.这个对象看起来似乎修改了它的类

类图

各组件描述:

Context:定义了和客户程序的接口,它保持了一个ConcreteState的代表现在状态的实例

State:状态接口,子类封装各个状态下行为
ConcreteState:State的子类

使用状态模式的情况

1. 对象的行为依赖于状态,对象再运行时改变状态
2. 操作有大量依赖于状态的条件语句

优点

1. 容易添加新的状态(因为封装在子类),
2. 状态迁移很明确

桥接模式

将对象的继承转为对象的组合

将一个软件设计的抽象部分和实现部分分离,使它们都可以独立地变化.

类图

各部分解释

1. Abstraction接口,定义抽象部分的接口,为吃Implementor对象的一个参考
2. RefinedAbstraction,继承或者实现Abstraction
3. Implementor:定义Implementation类的接口,接口形式可以不和Abstraction界面严格对应
4. ConcreteImplementor:实现Implementor接口

优点

1. 分离接口和实现部分,
2. 提高了可扩展性
3. 实现了细节对客户的透明

适配器模式

目的:解决接口不一致

分为类适配器模式和对象适配器模式

类图

类适配器: 写一个target接口声明所有需要的方法,写一个adaptor类继承adapee类,并且实现接口target

对象适配器:写一个target接口声明所有需要的方法,采用聚合的方法来实现adaptee类中的方法

使用适配器模式的情况

1. 想要使用现有的类,但现有类的接口不符合需求
2. 当需要通过创建一个可服用的类,是的本来接口不相容且无关的类结合在一起工作时
3. 在设计中需要改变多个子类接口,在作用相同但名称不同的类或方法之间进行适配时.

MVC

• 视图：管理作为位图展示到屏幕上的图形和文字输出；
• 控制器：翻译用户的输入并依照用户的输入操作模型和视图；
• 模型：管理应用的行为和数据，响应数据请求（经常来自视图）和更新状态的指令（经常来自控制器）；

如果用户通过一个View的Controller改变了Model,所有其他的View都必须反映出该改变.

当数据发生变化的时候,Model负责通知所有的View,告诉他们数据已经改变了