策略模式

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

各部分组成及说明

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,告诉他们数据已经改变了

复习

1.基本概念

软件体系结构

系统的基本组织结构,包括系统构成要素,这些构成要素之间以及与环境之间的关系,系统设计及演化时所应遵循的原则

什么设计模式?

是一套被反复使用,多数人知晓的,经过分类编目的,代码设计经验的总结.

为什么要用设计模式?

为了<u>可重用代码</u>,让代码更容易<u>被他人理解</u>,保证<u>代码可靠性</u>

非功能需求有哪些?,含义是什么?

1. 性能
2. 可扩展性/伸缩性
3. 可维护性
4. 可用性
5. 安全性
6. 业务质量
   成本,周期,投入的人力,需要的资源
7. 性能需求:用户在软件响应速度,结果精度,运行时资源消耗量等方面的要求
8. 可靠性需求:用户在软件失效的频率,严重程度,易恢复性,以及故障可预测性等方面的要求
9. 易用性要求:用户要求在界面的易用性,美观性,以及对面向用户的文档和培训资料等方面的要求
10. 安全性需求:用户在身份认证,授权控制,私密性等方面的要求
11. 运行环境约束:用户对软件系统运行环境的要求
12. 外部接口:用户对待开发的软件系统与其他软件系统或硬件设备之间的接口的要求
13. 可保障性要求:用户在软件可配置性,可扩展性,可维护性,可移植性方面的要求

编程的三个层次?

针对实现编程

Dog d = new Dog();

d.bark();

针对接口/超类型编程

Animal animal = new Dog();

animal.makeSound();

运行时才指定具体实现的对象

a=getAnimal();

a.makeSound();

设计模式的三大原则

单一职责

一个类只负责一个功能领域中相应的职责,

依赖倒置

针对接口编程,而非针对实现编程

即程序中所有的依赖关系都是终止与抽象类或者直接接口.

开闭原则

对拓展开放,对修改关闭

面向对象的三大原则

软件体系结构

分层风格

指将软件设计成层次结构,每个层为其上层服务,同时又是其下层的客户,不允许隔层调用

优点

1. 层次结构 支持基于随着层次不断增加而不断抽象的设计.能将一个复杂的问题分一系列从初等的与硬件相关的功能到可以被用户使用的高级功能.
2. 支持更新.每层只和两个层交互,因此,在接口不变的前提下,可以单独修改或更换某一层的某些组件而不影响其他层.
3. 支持复用.

缺点

1. 不是什么系统都容易被组织成层次结构
2. 有时层次结构的逻辑上的较高层级和较低层级会有比较紧密的耦合
3. 正确的层次抽象往往可能很困难.

管道-过滤器风格

每个过滤器都有一组输入和输出,组件读入输入数据流,经过数据处理,然后产生输出数据流.

系统由负责运送数据的管道和负责对数据进行处理的过滤器组成

优点

1. 高内聚低耦合
2. 允许设计者将整个系统的输入/输出行为看做是多个过滤器行为的简单合成
3. 支持软件重用
4. 系统维护和增强系统性能简单
5. 允许对一些如吞吐量,死锁等属性的分析
6. 支持并发

缺点

1. 导致进程称为批处理结构
2. 不适合处理交互应用
3. 因为每个过滤器上都增加了解析和合成数据的工作,因此系统性能下滑,

主程序-子程序风格

采取分而治之策略,将一个复杂的问题分解为多个独立的字问题

自顶向下功能化设计思想(结构化设计)

从功能需求出发,将一个整体问题分解为多个子问题,然后将子问题划分为几个更小的子问题,直到不可划分为止

优点

1. 逻辑设计与物理设计分开
2. 开发过程中形成一套规范化的文档,以便后期修改和维护

适用于组织相对稳定,业务处理过程规范,需求明确且在一定时期内不会发生大的变化的大型复杂系统的开发.

缺点:开发周期长,系统难以适应环境的变化及开发过程复杂繁琐

功能演化困难,显示中的系统功能不容易描述,功能化设计丢掉了数据与数据结构,产生的可复用代码少.

面向对象软件体系结构

系统看做由一些对象的集合构成,消息从一个对象发送到另外一个对象.每个对象都有其相关的功能

对象是一个具有状态和行为的实体.一个对象存储它的状态在域中,面向对象设计隐藏对象的内部状态,并且要求所有对象之间的交互都通过该对象的方法,这叫做数据封装,是面向对象编程的基本原则.

面向对象设计的特点

1. 封装性,限制对特定信息的访问
2. 继承性,共享同一个功能定义
3. 动态绑定性:在程序运行前,不知道创建哪个类的对象,运行时才动态生成
4. 复用和可维护性:因为封装与局部化
5. 系统功能通过对象服务表示:对象的接口提供了一系列的方法.
6. 共享数据区域被取消
7. 对象可以是分布的.通过函数或者方法调用互相交互.
8. 对象是对现实世界的抽象并且可以自己管理自己.

优缺点

优点:

1. 容易维护
2. 可复用性好
3. 映射现实世界
4. 容易对一个系统进行剖分

缺点

1. 占用欧冠内存较大.因为每个新被创建的对象都必须占用一块内存,而面向对象程序中,往往有大量对象被创建
2. 一个对象要和另外一个对象交互,该对象必须知道另外一个对象的身份,包括对象名,方法名和参数类型等.

基于共享数据的事件风格

1. 系统中的每个组件可以注册一种事件
2. 当一个组件要发布事件时,该组件可以广播一个或多个事件到事件空间
3. 每当一个事件被广播了,系统将负责自动调用那些已经注册了该事件的组件或者过程,被调用的组件将运行.

2.设计模式

mvc模式

model 包含核心数据和功能,独立于输入行为和输出表示

View 将模型中的数据显示给用户

Controller处理用户输入,如果用户通过一个view 的controller改变了model,其他controller必须反映出该改变,即当数据发生变化的时候,model负责同志所有的view,告诉他们数据已经改变了.(观察者模式,model对象是被观察者,controller是观察者)

优缺点

优点

1. 对于同一个模型,可以有不同的视图和控制器,一遍提供给用户不同类型的用户图形界面
2. 改变-传播机制保证了模型在改变的同时自动刷新所有的视图
3. mvc体系结构的设计使的改变图形界面非常容易,适合业务逻辑较少改变,而图形界面需要经常改变的应用
4. 全部的核心数据和核心功能都包含在模型中,很容易对核心的应用进行测试
5. 可拓展性比较好

命令模式

三个部件

客户程序

调用者程序

被调用者程序

解除调用者类与被调用者类的耦合–为响应客户新请求的行动创建一个抽象

client对象负责初始化Command对象,并且提供将来要调用的方法的全部信息

Invoker决定什么时候调用所要调用的方法

receiver是含有索要调用方法的代码的实例

3.期末复习