哈工大软件构造课程设计模式有感

今日在软件构造课上，我们学习了面向可复用性和可维护性的设计模式，我觉得可能对于一些应付考试的大学生来讲或许没什么用，因为我们的老师在给我们留实验的时候不会说突然改变要求，但是客户可不管这一套！他会随时更改需求，所以我们以后上班时候，有一个很好的编程模式，对于我们更改代码，满足客户的需求就会变得很容易了，下面我来表达一下我对这几种模式的理解（也还没有太理解透，请大家帮我纠错）。

首先这种设计模式大概分为三类：创建型模式、结构型模式、行为型模式。下面我会一一说一下我的理解。

首先是创建型模式，我要介绍的就是其中的工厂方法模式，所谓工厂方法模式解决的就是一个客户不知道创建哪一个类的问题，而这种模式对此的解决方法就是：我定义一个专门用来创建对象的接口，让它的子类来决定创建哪一个对象。就是说，客户可以将创建对象这个问题抛给程序，让程序来选择创建哪一个对象（说白了就是程序员把创建对象的选择这件事也给包了，客户只需要输入一些基本的信息，程序来创建对象）。

这里给出一个例子：

这里，TraceFactory接口就是来实现创建对象的接口，然后下面getTrace方法就给客户创建一个对象，选择性一般就是通过if语句来体现。当然如果程序没那么复杂，你不想定义接口，你就直接用一个类来实现创建对象操作即可。

下面说一下结构型模式：适配器模式（adapter）、装饰器模式（decorator）。

适配器模式：将某个类/接口转换成为客户期望的其他形式（说白了就是客户的需求/spec变了）。

这里用一个图就比较好理解了：

 我的理解就是，客户呢更改了他的需求，比如说他们能加了一些方法，而我们之前的类只能实现他之前的方法，这个时候我们增加一个接口将之前的子类包装起来，这个时候我们的子类只能实现那些之前的方法，可是增加的方法怎么办呢？这里通过delegation委派给其他类来做，就完成了这个结构了。

装饰器模式：让每个子类实现不同的特性。这个就有意思了，这个里面用到了一个自己委派自己的机制，如下图：

装饰器通过自己委派自己，将父类那些功能实现，然后在实现基本方法的基础上再在它的子类中增加一些新特性，这里我之前有个疑问，为什么增加新特性不直接在父类操作呢，而要造一个装饰器来过度呢？（我的同学给了我一些答案，也供大家探讨：因为父类有很多的子类，所以尽量不要直接对父类进行操作，容易影响别的子类的继承）。

最后说一下行为模式：策略模式、模板模式、迭代器（Iterator）、Visitor

策略模式（strategy）：这个看一下图就明白了，也是经常用，就是你一个任务你会定义一个实现，但是如果客户要求用另一种方法去实现，你去改代码就很麻烦，你可以将这个任务委派给ADT，然后当你要改的时候只需在ADT中增加一个方法即可。如图：

模板模式（template）：这个就更常见了，它的特点是只是用继承，那这样怎么提升复用性呢，很简单：只要把共性的东西放在父类就好了，这样子类就不用再写了，这里略写。

迭代器（Iterator）：这个就类比list那些集合的迭代器，我想遍历一组ADT对象，我用不同直接用iterator方法，那怎么办呢？我们自己定义一个Iterator方法，在里面返回一个自定义ConcreteIterator 类实现Iterator接口，并且重写其中的next、hasNext、remove方法即可，这样就可以按照list一样进行迭代了。如图：

visitor：visitor模式我认为是一种比较难以理解的模式了，他应用于一个什么场景呢？就是：某种特定类型的object对应于特定的操作，我们为了灵活更改代码，将两个动态绑到一起。如图：

 

这种动态绑定体现在哪里呢，我认为体现在visitor和concretevisitor中，即你输入的visitor类型于你的实现方法时绑定的，我们面对客户时，暴漏的只有accept方法，客户只需要输入想操作的visitor即可，然后通过accept委派给visitor，最后在visitor中调用visit方法，来与visit对应的实现类动态绑定并实现，也就是说这种模型将实现方法与类型绑定在了一起，适用于这种开发场景，而客户看起来任何类型的输入，调用的代码都是一样的，这样会使客户的使用体验很好。

以上就是我对于这些设计模式的个人理解，如果有的地方不对，还请指正。