软件构造学习笔记（5）

最新推荐文章于 2024-07-24 17:05:18 发布

kinza99

最新推荐文章于 2024-07-24 17:05:18 发布

阅读量125

点赞数

文章标签：学习

本文链接：https://blog.csdn.net/kinzad/article/details/125197998

版权

哈工大软件构造课程学习笔记（5）

前言

一、面向可复用性和可维护性的设计模式

1.Creational patterns

工厂方法模式

2.Structural patterns

(1)适配器模式

(2)装饰器模式

3.Behavioral patterns

1.Error and Exception

2.Assertions

3.防御式编程

总结

前言

本文具体讲解了面向可复用性和可维护性的设计模式和面向正确性与健壮性的软件构造

一、面向可复用性和可维护性的设计模式

这里将讲解的设计模式分为三大类Creational patterns、Structural patterns和Behavioral patterns。

1.Creational patterns

工厂方法模式

要解决的问题：当client不知道/不确定要创建哪个具体类的实例，或者不想在client代码中指
明要具体创建的实例时，用工厂方法。

解决方案：定义一个用于创建对象的接口，让该接口的子类型来决定实例化哪一个类，从而使一个类的实例化延迟到其子类。

常规情况下，client直接创建具体对象，但是是一种表示泄漏。

在工厂模式下，先定义一个公共的接口，之后对于每一种具体类型，用一个实现公共接口的具体的类的静态方法来产生具体类型，这样可以很好的方式表示泄漏。

相比于通过构造器(new)构建对象：

1. 静态工厂方法可具有指定的更有意义的名称

2. 不必在每次调用的时候都创建新的工厂对象

3. 可以返回原返回类型的任意子类型

2.Structural patterns

(1)适配器模式

要解决的问题：解决类之间接口不兼容的问题

解决方案：通过增加一个接口，将已存在的子类封装起来，client面向接口编程，从而隐藏了具体子类。

本质上来讲，就是把适配器原本不适配子类的代替，适配器可以继承或者委托原本不适配的类，注意，适配器也是一个类。

(2)装饰器模式

要解决的问题：为对象增加不同侧面的特性

解决方案：对每一个特性构造子类，通过委派机制增加到对象上

Decorator抽象类是所有装饰类的基类，里面包含的成员变量，在抽象类中委托给被修饰的类来完成所有基础功能，具体的修饰类继承Decorator抽象类，只需按需要增加修饰。

如果客户端需要一个具有多种特性的object，通过一层一层的装饰来实现，就像一层一层的穿衣服。

3.Behavioral patterns

(1) 策略模式

要解决的问题：有多种不同的算法来实现同一个任务，但需要client根据需要动态切换算法，而不是写死在代码里

解决方案：为不同的实现算法构造抽象接口，利用delegation，运行时动态传入client倾向的算法
类实例

总结：先定义一个策略接口，是对所有具体策略的抽象，包含具体策略的共同的方法。之后具体的策略类只需实现接口就好。在使用策略的类中，将希望具体策略完成的算法委托给策略接口的某一个实现即可，不同实现可以用参数来区分等。

(2) 模板模式

要解决的问题：做事情的步骤一样，但具体方法不同

解决方案：共性的步骤在抽象类内公共实现，差异化的步骤在各个子类中实现。模板方法定义了一个算法的步骤，并允许子类为一个或多个步骤提供实现。

总结：简单来讲就是用一个抽象类来将做事情的步骤一样，但具体方法不同每个具体类的做事步骤抽象出来，具体类继承抽象类，差异在于每个方法的实现不同，一般会增加一个方法来按顺序调用事情的步骤的方法。

(3) Iterator

要解决的问题：客户端希望对放入容器/集合类的一组ADT对象进行遍历访问，而无需关心容器的具体类型

解决方案：使用迭代器

总结：第一步，另要被遍历的集合实现Iterable接口，第二步实现自己的独特Iterator迭代器(hasNext, next, remove)，允许客户端委托这个迭代器进行显式或隐式的迭代遍历。

(4) Visitor

对特定类型object的特定操作(visit)，在运行时将二者动态绑定到一起，该操作可以灵活更改，无需更改被visit的类。

本质上：将数据和作用于数据上的某种/些特定操作分离开来。

总结：特点就是实现一个额外的ADT（一般是接口+类），只不过这个ADT优点特殊，在正在实现的类中，使用如accept()方法来将一些特定的操作分离委托给ADT实现，而在ADT的实现过程中，还要对当前类委托，利用当前类的一些属性和数据之类的，也就是形成了双向委托。

二、面向正确性与健壮性的软件构造

健壮性：系统在不正常输入或不正常外部环境下仍能够表现正常的程度

面向健壮性的编程希望：处理未期望的行为和错误终止；即使终止执行，也要准确/无歧义的向用户展示全面的错误信息

正确性：程序按照spec加以执行的能力，是最重要的质量指标！

正确性倾向于直接报错(error)，健壮性则倾向于容错(fault-tolerance)

可靠性=健壮性+正确性

可以通过平均故障间隔时间（MTBF）（平均无故障运行时间），是指相邻两次故障之间的平均工作时间，来衡量健壮性。

MTBF用于描述可修复系统的平均无故障运行时间，MTTF（故障前平均时间）描述不可修复系统的故障前平均时间

1.Error and Exception

这里有两种很重要的分类，分类一：

Error：程序员通常无能为力，一旦发生，想办法让程序优雅的结束，通常是一些外部的不可抗力导致的。

Exception：程序执行中的非正常事件，导致程序无法再按预想的流程执行。是你自己程序导致的问题，可以捕获、可以处理。

其中由于error难以处理，重点关注Exception。首先Exception和Error都是继承自Throwable类的，其中Exception又分为 RuntimeException和其它，单独分出RuntimeException的原因是RuntimeException比较特殊，运行时异常，是程序源代码中引入的故障所造成的，如果在代码中提前进行验证，这些故障就可以避免；而其它异常即使在代码中提前加以验证（如：文件是否存在），也无法完全避免失效发生，是程序员无法完全控制的外在问题所导致的。

这就引出了第二个重要分类：

Checked exceptions：包括Exception中除了RuntimeException的所有异常，这些既是异常，又是无法完全避免失效发生的。可以理解为需要检查的异常。

unchecked exceptions：包括Error所有和RuntimeException，可以理解为没有检查的必要，Error检查了也无能为力，RuntimeException检查的话会降低对程序员的要求，掩耳盗铃。

对与Checked exceptions，必须捕获并指定错误处理器handler，否则编译无法通过；unchecked exceptions则不需要。

处理Checked exceptions，会用到如下关键字：

(throws) 声明“本方法可能会发生XX异常”
(throw) 抛出XX异常
(try, catch, finally) 捕获并处理XX异常

注： Unchecked异常也可以使用throws声明或try/catch进行捕获，但大多数时候是不需要的，也不应该这么做，是掩耳盗铃，对发现的编程错误充耳不闻的行为。

什么时候使用Checked exceptions，什么时候使用Unchecked呢？

如果客户端可以通过其他的方法恢复异常，那么采用checked exception；

如果客户端对出现的这种异常无能为力，那么采用unchecked exception；

总结起来就是如下的表：