软件架构设计基础面向模式的分析设计与实现PPT文档格式.ppt

软件架构设计基础面向模式的分析设计与实现PPT文档格式.ppt

《软件架构设计基础面向模式的分析设计与实现PPT文档格式.ppt》由会员分享，可在线阅读，更多相关《软件架构设计基础面向模式的分析设计与实现PPT文档格式.ppt（84页珍藏版）》请在冰豆网上搜索。

症。

n通过基于上下文设计，我们可以在进行细节设计通过基于上下文设计，我们可以在进行细节设计时，不至于迷失，时刻了解全局。

时，不至于迷失，时刻了解全局。

什么是模式？

n模式是在一个模式是在一个特定上下文特定上下文中，针对一个中，针对一个不断出现不断出现的的问题的问题的最佳解决方案最佳解决方案n也可以把模式看作是对问题领域中实体（对象）之也可以把模式看作是对问题领域中实体（对象）之间关系的描述间关系的描述n模式为我们提供了一种新的建模技术：

模式为我们提供了一种新的建模技术：

n封装行为上的变化封装行为上的变化n强调设计中的即插即用能力强调设计中的即插即用能力n关注开放封闭原则关注开放封闭原则n可以建立并增强用于专业交流的语言，提升交流的可以建立并增强用于专业交流的语言，提升交流的效果和效率效果和效率n两个木匠在探讨如何造一个柜子两个木匠在探讨如何造一个柜子n其中一个说：

其中一个说：

“我们应该先向下切割，然后再我们应该先向下切割，然后再45度度向上切割向上切割”n“接着，再向下，然后再从另外一个接着，再向下，然后再从另外一个方向向上，再向下方向向上，再向下”n不停这样重复，直到完成不停这样重复，直到完成木匠行业中的一个模式示例木匠行业中的一个模式示例他们所讨论的就是燕尾槽他们所讨论的就是燕尾槽斜面接合斜面接合通常应用于相框通常应用于相框模式在各个层面都适用模式在各个层面都适用分析分析/动机动机设计设计实现实现燕尾槽斜面接合燕尾槽斜面接合结实、成本高不结实、成本低好看、防潮易于制作、适合于画框交织接合单面接合齿0.5寸长，0.445度切割，粘合寸深切割关注细节、忽视全局关注细节、忽视全局n过于注重如何实现燕尾槽的细节，会致使我们忽视过于注重如何实现燕尾槽的细节，会致使我们忽视最开始为何需要燕尾槽的动机最开始为何需要燕尾槽的动机n燕尾槽和斜面接合分别强调了：

燕尾槽和斜面接合分别强调了：

n我们是需要一种美观又经久耐用，但是制作成本高的接合方式呢我们是需要一种美观又经久耐用，但是制作成本高的接合方式呢n还是一种无需太结实，但是易于制作且成本低廉的接合方式还是一种无需太结实，但是易于制作且成本低廉的接合方式在增加功能时，问题会出现在哪里？

在增加功能时，问题会出现在哪里？

n代码编写中吗？

代码编写中吗？

n集成中吗？

集成中吗？

n哪个更严重一些？

哪个更严重一些？

n为何？

为何？

为何需要学习模式为何需要学习模式n重用已有的、高质量的解决方案重用已有的、高质量的解决方案n改进设计，使其易于修改改进设计，使其易于修改n开创一种新的面向对象设计范型开创一种新的面向对象设计范型n一种有助于学习的通用术语一种有助于学习的通用术语n我们会发现设计不是一个合成的过程，而是我们会发现设计不是一个合成的过程，而是一个逐步分化的过程一个逐步分化的过程n转向一种新的思考方式转向一种新的思考方式三个层次的视图三个层次的视图n概念层视图概念层视图n规格说明层视图规格说明层视图n实现层视图实现层视图MartinFowlerUMLDistilled不同层次视图的区别不同层次视图的区别n概念层：

概念层：

n描述了你想要什么，不关心如何得到它描述了你想要什么，不关心如何得到它n需求通常在概念层进行描述需求通常在概念层进行描述n“我们需要以的方式处理请求我们需要以的方式处理请求”n规格说明层：

规格说明层：

n类的接口类的接口n对象之间如何交互对象之间如何交互n实现层：

实现层：

n代码代码看看这三样东西看看这三样东西拖把拖把扫帚扫帚海绵海绵它们一样还是不同？

它们一样还是不同？

n谁认为它们是没有区别的？

谁认为它们是没有区别的？

n谁认为它们是有区别的？

谁认为它们是有区别的？

要视情况而定！

n从具体的物体角度出发：

它们是不同的从具体的物体角度出发：

它们是不同的n从概念角度出发：

它们都是清洁工具从概念角度出发：

它们都是清洁工具实际存在实际存在“清洁工具清洁工具”这个东西吗？

这个东西吗？

在现实世界中，是不存在现实世界中，是不存的。

但是它在我们的思的。

但是它在我们的思考中，作为一种考中，作为一种抽象分抽象分类类存在！

存在！

“清洁工具清洁工具”是不存的，是不存的，但是特定种类的清洁工但是特定种类的清洁工具是存在的！

具是存在的！

抽象类（抽象类（AbstractClass）n表示一个概念，因此无法被实例化表示一个概念，因此无法被实例化n用来为表示实际实体的类定义接口（也就是说，用来为表示实际实体的类定义接口（也就是说，如何定义如何与从抽象派生出来的对象进行交如何定义如何与从抽象派生出来的对象进行交互）互）n例如，例如，“清洁工具清洁工具”就是拖把、扫帚和海绵的就是拖把、扫帚和海绵的抽象类抽象类建模视角建模视角这是一个多态的例子这是一个多态的例子n允许存在不同的行为允许存在不同的行为n向对象发消息时，无需知道确切的对象类型向对象发消息时，无需知道确切的对象类型n向对象发消息时，只需要知道其概念类型向对象发消息时，只需要知道其概念类型n在上面的例子中，任何拥有拖把、扫帚或者海在上面的例子中，任何拥有拖把、扫帚或者海绵的对象只需知道它所拥有的是绵的对象只需知道它所拥有的是“清洁工具清洁工具”即可即可从不同的视图看对象从不同的视图看对象n从实现层看：

从实现层看：

n具有方法的数据具有方法的数据n从规格说明层看：

从规格说明层看：

n契约的实现体契约的实现体n从概念层看：

从概念层看：

n具有职责的实体具有职责的实体封装封装（Encapsulation）n通常会认为封装是对象层的东西（数据隐藏）通常会认为封装是对象层的东西（数据隐藏）n其实，我们经常会看到可以使用封装隐藏一其实，我们经常会看到可以使用封装隐藏一组类（比如，所有的派生类）组类（比如，所有的派生类）n抽象类和接口在本质上封装了其所有的派生抽象类和接口在本质上封装了其所有的派生类和实现类和实现使用者根本无需知道它们的存在使用者根本无需知道它们的存在n封装其实要隐藏的是决策和规则，那些容易封装其实要隐藏的是决策和规则，那些容易变化的决策和规则。

最好把每个这样的决策和变化的决策和规则。

最好把每个这样的决策和规则封装在一个地方规则封装在一个地方封装和模式封装和模式n在某种程度上，可以把模式看成是对如下在某种程度上，可以把模式看成是对如下东西进行封装的一种反映东西进行封装的一种反映n变体变体n设计决策设计决策n数量数量n结构结构n构造方法构造方法n等等等等一个简单的例子：

一个简单的例子：

消息处理系统消息处理系统问题问题n我们要开发一个消息处理系统我们要开发一个消息处理系统n该系统会收到不同类型的消息该系统会收到不同类型的消息n基于消息的类型，需要不同的处理算法基于消息的类型，需要不同的处理算法初始方案初始方案MessageProcessorMessageMessageProcessor负责实例化负责实例化Message对对象，象，Message对象来完成消息的处理逻辑对象来完成消息的处理逻辑面临挑战面临挑战n每当增加一种新的消息处理算法时，就得修改每当增加一种新的消息处理算法时，就得修改Message对象对象n我们还可能会造成我们还可能会造成“GodObject”的问题，一的问题，一个大的对象承担了太多的职责个大的对象承担了太多的职责n“GodObject”是违背面向对象原则的是违背面向对象原则的n必需以过程化的方法完成所有的行为必需以过程化的方法完成所有的行为n以后行为的变化会导致对代码的更改以后行为的变化会导致对代码的更改n破坏了对象的封装性破坏了对象的封装性n全局数据过程化的代码全局数据过程化的代码新需求新需求多种消息处理类型多种消息处理类型我们需要处理两种不同类型的消息我们需要处理两种不同类型的消息nTYPE_AnTYPE_B一种解决方案：

一种解决方案：

methodprocessMessage/使用基于消息类型的使用基于消息类型的switch语句进行判断语句进行判断/TYPE_A:

/使用类型使用类型A的算法处理消息的算法处理消息/break/TYPE_B:

/使用类型使用类型B的算法处理消息的算法处理消息/break使用继承进行特化使用继承进行特化我们可以通过特化最初的我们可以通过特化最初的Message对象来处理对象来处理新的消息类型新的消息类型MessageProcessorMessage+process（）Message_B+process（）原来类型消息原来类型消息的处理方法的处理方法新（覆写）的类新（覆写）的类型型B消息的处理消息的处理方法方法这会导致重复和维护性方面的问题这会导致重复和维护性方面的问题n如果再有新的变体，把它放在哪里呢？

如果再有新的变体，把它放在哪里呢？

n要么使用大量的要么使用大量的switch语句（这会导致代语句（这会导致代码难以理解），要么过渡的特化（这同样会码难以理解），要么过渡的特化（这同样会导致很多麻烦）导致很多麻烦）n这种方法把这种方法把Type_A和和Type_B耦合在一起，耦合在一起，当前可能没有问题，但是存在很大隐患当前可能没有问题，但是存在很大隐患n我们希望能够把变化封装起来我们希望能够把变化封装起来一个好一点的方案一个好一点的方案通过抽象来解耦通过抽象来解耦Type_A和和Type_B的处理的处理MessageProcessorMessage+process（）Message_B+process（）抽象基类，消除抽象基类，消除重复重复新（覆写）的类新（覆写）的类型型B消息的处理消息的处理方法方法Message_A+process（）新（覆写）的类新（覆写）的类型消息的处理型消息的处理方法方法同样会导致维护性方面的问题同样会导致维护性方面的问题n如果再有新的变体，把它放在哪里呢？

n可以再次继承，但是会产生非常多的类可以再次继承，但是会产生非常多的类（组合爆炸）（组合爆炸）n级联继承导致很多耦合问题级联继承导致很多耦合问题n对变化的封装度弱对变化的封装度弱很可能出现的结果很可能出现的结果MessageProcessorMessageMessage_AMessage_CMessage_BMessage_DMessage_A_CMessage_B_D看看看看GangofFour的建议的建议Gamma,Helms,Johnson,VlissidesDesignPatterns:

ElementsofReusableObject-OrientedDesign的位作者GangofFour给我们提供的指南给我们提供的指南n面向接口编程面向接口编程n对象组合对象组合优于优于类继承类继承n发现设计中的变化，并把变化的概念封装起来发现设计中的变化，并把变化的概念封装起来n发现变化，并用一个类来封装它发现变化，并用一个类来封装它n把该类包含在另一个类中，以避免类继承中出现多个变体把该类包含在另一个类中，以避免类继承中出现多个变体发现变化，封装变化发现变化，封装变化n识别出变化的识别出变化的行为行为n定义一个类把变化封装起来，然后通过组合的方定义一个类把变化封装起来，然后通过组合的方式把从该抽象类派生的具体类实例包含进来式把从该抽象类派生的具体类实例包含进