11结构型设计模式.pptVIP

结构型设计模式 姜中华 大纲 结构型模式的特点 Adapter模式 Bridge模式 Decorator模式 Facade模式 结构型模式的特点 结构型模式的共同点 结构型模式涉及到如何组合类和对象以获得更大的结构 结构型类模式采用继承机制组合接口或实现 结构型对象模式不是对接口和实现进行组合，而是描述了如何对一些对象进行组合，从而实现新功能的一些方法 ADAPTER—类对象结构型模式 目的：将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。 动机：有时，为复用而设计的工具箱类不能够被复用的原因仅因为它的接口与专业应用领域所需要的接口不匹配。 案例---一个图形编辑器 案例---待解决的问题 像LineShape和PolygonShape基本几何图形比较容易实现(绘图和编辑功能很有限)。 但对于可显示和编辑正文的TextShape子类来说，实现相当困难，因为即使是基本的正文编辑也要涉及到复杂的屏幕刷新和缓冲区管理。 已有的GUI工具箱可能已经提供了一个复杂的TextView类。理想的情况是我们可以复用这个TextView类以实现TextShape类。 但是工具箱的设计者当时并没有考虑Shape的存在，因此TextView和Shape对象不能互换。 接口互不兼容的解决方法 改变TextView类使它兼容Shape类的接口，前提是必须有这个工具箱的源代码。不应该仅为了实现一个应用，工具箱被迫采用与特定领域相关的接口。 定义一个TextShape类，由它来适配TextView的接口和Shape的接口。两种方法如下： 继承Shape类的接口和TextView的实现 将一个TextView实例作为TextShape的组成部分，并且使用shapeTextView的接口实现TextShape 这两种方法恰恰对应于Adapter模式的类和对象版本。我们将TextShape称之为适配器Adapter。 案例的类框图 Bridge---对象结构型模式 目的：将抽象部分与它的实现部分分离，使它们都可以独立地变化。 动机：当一个抽象可能有多个实现时，通常用继承来协调它们。抽象类定义对该抽象的接口，而具体的子类则用不同方式加以实现。但此方法有时不够灵活。继承机制将抽象部分与它的实现部分固定在一起，使得难以对抽象部分和实现部分独立地进行修改、扩充和重用。 案例---用户界面工具箱 案例---继承机制的不足之处 扩展Window抽象使之适用于不同种类的窗口或新的系统平台很不方便。假设有Window的一个子类IconWindow，它专门将Window抽象用于图标处理。为了使IconWindow支持两个系统平台，我们必须实现两个新类XIconWindow和PMIconWindow，更为糟糕的是，我们不得不为每一种类型的窗口都定义两个类。 继承机制使得客户代码与平台相关。每当客户创建一个窗口时，必须要实例化一个具体的类，这个类有特定的实现部分。例如，创建Xwindow对象会将Window抽象与XWindow的实现部分绑定起来，这使得客户程序依赖于XWindow的实现部分。这将使得很难将客户代码移植到其他平台上去。 理想目标 客户在创建窗口时应该不涉及到其具体实现部分。仅仅是窗口的实现部分依赖于应用运行的平台。这样客户代码在创建窗口时就不应涉及到特定的平台。 Bridge模式解决: 将Window抽象和它的实现部分分别放在独立的类层次结构中。一个结构针对窗口接口(Window，IconWindow，TransientWindow)，另外一个针对平台相关的窗口实现部分，其根类为WindowImp。例如XwindowImp子类提供了一个基于XWindow系统的实现。 Window与WindowImp之间的关系称之为桥接，因为它在抽象类与它的实现之间起到了桥梁作用，使它们可以独立地变化。 Bridge的适应场合 不希望在抽象和实现部分有一个固定的绑定关系。 类的抽象以及它的实现都应该可以通过生成子类的方法加以扩充。 对一个抽象的实现部分的修改应对客户不产生影响，即客户的代码不必重新编译。 (C++)你想对客户完全隐藏抽象的实现部分。 这种类层次要求将一个对象分解成两个部分。 你想在多个对象间共享实现，但同时要求客户并不知道这一点。 理想目标 Bridge模式的类框图 Bridge模式的类框图 Bridge的参与者 Abstraction (Window)：定义抽象类的接口；维护一个指向Implementor类型对象的指针。 RefinedAbstraction(IconWindow):扩充Abstraction接口 Implementor (WindowImp):定义实现类的接口，该接口不一定要与A