第六章设计模式引言讲述.ppt

几个概念的区分 模式： 设计模式： 框架： 架构： 设计模式所支持的设计的可变方面 设计模式所支持的设计的可变方面 6.9 怎样使用设计模式 1) 大致浏览一遍模式 特别注意其适用性部分和效果部分，确定它适合你的问题。 2 ) 回头研究结构部分、参与者部分和协作部分 确保你理解这个模式的类和对象以及它们是怎样关联的。 3 ) 看代码示例部分，看看这个模式代码形式的具体例子 研究代码将有助于你实现模式。 4 ) 选择模式参与者的名字，使它们在应用上下文中有意义 设计模式参与者的名字通常过于抽象而不会直接出现在应用中。然而，将参与者的名字和应用中出现的名字合并起来是很有用的。这会帮助你在实现中更显式的体现出模式来。 怎样使用设计模式（续） 5) 定义类 声明它们的接口，建立它们的继承关系，定义代表数据和对象引用的实例变量。识别模式会影响到的你的应用中存在的类，做出相应的修改。 6) 定义模式中专用于应用的操作名称 这里再一次体现出，名字一般依赖于应用。使用与每一个操作相关联的责任和协作作为指导。还有，你的名字约定要一致。例如，可以使用“Create-”前缀统一标记Factory方法。 7) 实现执行模式中责任和协作的操作 实现部分提供线索指导你进行实现。代码示例部分的例子也能提供帮助。 6.10 设计模式怎样解决设计问题 设计应支持变化 设计模式可以确保系统能以特定方式变化，从而帮助避免重新设计系统。 每一个设计模式允许系统结构的某个方面的变化独立于其他方面，这样产生的系统对于某一种特殊变化将更健壮。 设计模式怎样解决设计问题（续） 导致重新设计的原因，以及解决问题的设计模式 通过显式地指定一个类来创建对象 在创建对象时指定类名将使你受特定实现的约束而不是特定接口的约束。这会使未来的变化更复杂。要避免这种情况，应该间接地创建对象。 设计模式： Abstract Factory，Factory Method，Prototype。 设计模式怎样解决设计问题（续） 导致重新设计的原因，以及解决问题的设计模式 对特殊操作的依赖 当你为请求指定一个特殊的操作时，完成该请求的方式就固定下来了。为避免把请求代码写死，你将可以在编译时刻或运行时刻很方便地改变响应请求的方法。 设计模式： Chain of Responsibility，Command。 设计模式怎样解决设计问题（续） 导致重新设计的原因，以及解决问题的设计模式 对硬件和软件平台的依赖 外部的操作系统接口和应用编程接口( API )在不同的软硬件平台上是不同的。依赖于特定平台的软件将很难移植到其他平台上，甚至都很难跟上本地平台的更新。所以设计系统时限制其平台相关性就很重要了。 设计模式： Abstract Factory，Bridge。 设计模式怎样解决设计问题（续） 导致重新设计的原因，以及解决问题的设计模式 对对象表示或实现的依赖 知道对象怎样表示、保存、定位或实现的客户在对象发生变化时可能也需要变化。对客户隐藏这些信息能阻止连锁变化。 设计模式： Abstract Factory，Bridge，Memento，Proxy 设计模式怎样解决设计问题（续） 导致重新设计的原因，以及解决问题的设计模式 对对象表示或实现的依赖 知道对象怎样表示、保存、定位或实现的客户在对象发生变化时可能也需要变化。对客户隐藏这些信息能阻止连锁变化。 设计模式： Abstract Factory，Bridge，Memento，Proxy 设计模式怎样解决设计问题（续） 导致重新设计的原因，以及解决问题的设计模式 算法依赖 算法在开发和复用时常常被扩展、优化和替代。依赖于某个特定算法的对象在算法发生变化时不得不变化。因此有可能发生变化的算法应该被孤立起来。 设计模式： Builder，Iterator，Strategy，Template Method，Visitor 设计模式怎样解决设计问题（续） 导致重新设计的原因，以及解决问题的设计模式 紧耦合 紧耦合的类很难独立地被复用，因为它们是互相依赖的。紧耦合产生单块的系统，要改变或删掉一个类，你必须理解和改变其他许多类。这样的系统是一个很难学习、移植和维护的密集体。松散耦合提高了一个类本身被复用的可能性，并且系统更易于学习、移植、修改和扩展。设计模式使用抽象耦合和分层技术来提高系统的松散耦合性。 设计模式： Abstract Factory，Command，Facade，Mediator，Observer ，Chain of Responsibility。 设计模式怎样解决设计问题（续） 导致重新设计的原因，以及解决问题的设计模式 通过生成子类来扩充功能 通常很难