软件工程的23种设计模式的UML类图.docxVIP

二十二种设计模式 0引言 谈到设计模式，绝对应该一起来说说重构。重构给我们带来了什么？除了作为对遗留代码的改进 的方法，另一大意义在于，可以让我们在写程序的时候可以不需事先考虑太多的代码组织问题， 当然这其中也包括了应用模式的问题。尽管大多数开发者都已经养成了写代码前先 从设计开始 的习惯，但是，这种程度的设计， 涉及到到大局、到总体架构、到主要的模块划分我觉得就够了。 换句话说，这时就能写代码了。这就得益于重构的思想 了。如果没有重构的思想，有希望获得 非常高质量的代码，我们就不得不在开始写代码前考虑更多其实并非非常稳定的代码组织及设计 模式的应用问题，那开发效率 当然就大打折扣了。在重构和设计模式的合理应用之下，我们可 以相对较早的开始写代码，并在功能尽早实现的同时，不断地通过重构和模式来改善我们的代码 质 量。所以，下面的章节中，在谈模式的同时，我也会谈谈关于常用的这些模式的重构成本的 理解。重构成本越高意味着，在遇到类似的问题情形的时候，我们更应该 提前考虑应用对应的 设计模式，而重构成本比较低则说明，类似的情形下，完全可以先怎么方便，怎么快怎么写，哪 怕代码不是很优雅也没关系，回头再重构也很容 易。 1创建型 1.1FactoryMethod 思想：Factory Method 的主要思想是使一个类的实例化延迟到其子类。 场景：典型的应用场景如：在某个系统开发的较早阶段，有某些类的实例化过程，实例化方式 可能还不是很确定，或者实际实例化的对象（可能是需要对象的某个子类中的一 个）不确定， 或者比较容易变化。此时，如果直接将实例化过程写在某个函数中，那么一般就是 if-else 或 select-case 代 码。如果，候选项的数目较少、类型基本确定，那么这样的 if-else 还是可以 接受的，一旦情形变 得复杂、不确定性增加，更甚至包含这个构造过程的函数所在的类包含几 个甚至更多类似的函数时，这样的 if-else 代 码就会变得比较不那么容易维护了。此时，应用 本模式，可以将这种复杂情形隔离开，即将这类不确定的对象的实例化过程延迟到子类。 实现：该模式的典型实现方法就是将调用类定义为一个虚类， 在调用类定义一个专门用于构造不 确定的对象实例的虚函数，再将实际的对象实例化代码 留到调用类的子类来实现。如果，被构 造的对象比较复杂的话， 同时可以将这个对象定义为可以继承、 甚至虚类，再在不同的调用类的 子类中按需返回被构造类的子 类。 重构成本：低。该模式的重构成本实际上还与调用类自己的实例化方式相关。 如果调用类是通过 Factory 方 式（此处Factory 方式”泛指对象的实例化通过 Factory Method 或 Abstract Factory 这样的相对独立岀来的 方式构造）构造的，那么，重构成本相对就会更低。否则，重 构时可能除了增加调用类的子类，还要将所有实例化调用类的地方，修改为以新增的子类代替。 可能这样的子类还不止一个，那就可以考虑迭代应用模式来改善调用类的实例化代码。 1.2AbstractFactory 思想：不直接通过对象的具体实现类，而是通过使用专门的类来负责一组相关联的对象的创建。 场景：最典型的应用场景是：您只想暴露对象的接口而不想暴露具体的实现类， 但是又想提供实 例化对象的接口给用户；或者，您希望所有的对象能够 集中在一个或一组类（通常称作工厂类） 来创建，从而可以更方便的对对象的实例化过程进行动态配置 （此时只需要修改工厂类的代码或 配置）。 实现：该模式的实现是比较清晰简单的， 如上图，就是定义创建和返回各种类对象实例的工厂类。 在最复杂而灵活的情形，无论工厂类本身还是被创建 的对象类都可能需要有一个继承体系。简 单情形其实可以只是一个工厂类和需要被创建的对象类。 不一定非要像上图中结构那么完备 （累 赘）。 重构成本：中。如果一开始所有的对象都是直接创建，例如通过 new实例化的， 而之后想重构 为Abstract Factory模式，那么，很自然的我们需要替换所有直接的 new实 例化代码为对工厂 类对象创建方法的调用。考虑到像 Resharper这样的重构工具的支持，找岀对 某个方法或构造 函数的调用位置这样的操作相对还是比较容易， 重构成本也不是非常高。 同时，重构成本还和被 创建对象的构造函数的重载数量相关。您需要根据实 际情况考虑，是否工厂类要映射被创建对 象的所有重载版本的构造函数。 BuilderHu 肿ConcrctcBuildof * Builder Hu 肿 ConcrctcBuildof * Product Director Construct!.} g tor all objects in siructLire [ buiktor-^