外观+装饰模式.pptVIP

装饰模式 定义：装饰模式以对客户端透明的方式动态扩展对象的功能（附加新的职责），是继承关系的一个替代方案。 为什么要使用装饰模式？ 1）使用继承扩展对象的功能会导致类爆炸。 2）继承扩展是静态的；不能根据需要动态扩展。 什么情况下是用装饰模式 （1）在不影响其他对象的情况下，以动态且透明的方式添加单个对象的功能。 （2）需要动态的给一个对象增加功能，这些功能可以动态的撤销。 （3）需要增加由排列组合而产生大量的功能，从而使得继承关系不现实。 装饰模式 模式的角色： 1）抽象构件角色（Component ）：给出一个抽象接口，以规范接收附加责任的对象。 2）具体构件角色（ConcreteComponent ）：定义一个将要接受附加责任的类 3）装饰角色（Decorator ）：持有一个构件对象的实例，并定义一个与抽象构件一致的接口。 4）具体装饰角色（ConcreteDecorator ）：负责给构件对象贴上附加的责任。 特别注意：即装饰者和被装饰者具有相同的接口，这和代理模式很相似。 装饰模式 结构图：链式结构 装饰模式 优点： 1）把类中的装饰功能从类中移除，可以简化原有的类 2）把类中的核心职责和装饰功能区分开来，而且可以去除相关类中重复的装饰逻辑。 3）动态添加对象到某个对象上 缺点： 1）会导致比继承更多的对象，查错变得更加困难。 装饰模式 实现： 1）给一个人装饰各种饰物 2）星巴克咖啡加牛奶，巧克力的价格计算 3）打印各种类别的订单（表头和表尾可能不同） 装饰模式 Java I/O中的装饰模式 装饰模式 装饰模式与其他设计模式： 1）装饰模式和适配器模式都被称作包装模式，适配器模式是改变所考虑对象的接口，装饰模式是要保持接口，从而增强所考虑对象的性能。 2）装饰模式和代理模式一样都是使用委派机制来达成任务。都可以附加额外的行为； 总结 外观模式为子系统中的一组接口提供一个一致的界面 装饰模式不改变接口，但动态的加入责任或者行为。 作业 请使用外观模式, 编写一个类可以访问Oracle 请使用装饰模式将一幅画添加画框和蒙版。 请使用装饰模式将文件中的所有小写字符输出为大写字母。 * 病人会与这些部门打交道。就如一个客户类和很多子系统类交互一样。 * 提供一个统一的一致的接口：提供挂号，就诊，取药的功能。 Interface HospitalFacede{ public void guahao(); public void seeDoctor(); public void getMedicine(); } 病人只需要面对HospitalFacede接口就行了，而由HospitalFacede的实现类去和各个子系统比如：挂号子系统，就诊子系统，取药子系统打交道。 这样就减少了客户和各个子系统之间的耦合；子系统的变化不会涉及客户，只在子系统内部； * 外观模式是迪米特法则的一种体现。不和陌生人说话。 外观模式（Fa?ade pattern）涉及到子系统的一些类。所谓子系统，是为提供一系列相关的特征（功能）而紧密关联的一组类。例如，一个Account类、Address类和CreditCard类相互关联，成为子系统的一部分，提供在线客户的特征。 在真实的应用系统中，一个子系统可能由很多类组成。子系统的客户为了它们的需要，需要和子系统中的一些类进行交互。客户和子系统的类进行直接的交互会导致客户端对象和子系统之间高度耦合。任何的类似于对子系统中类的接口的修改，会对依赖于它的所有的客户类造成影响 外观模式（Fa?ade pattern）很适用于在上述情况。外观模式（Fa?ade pattern）为子系统提供了一个更高层次、更简单的接口，从而降低了子系统的复杂度和依赖。这使得子系统更易于使用和管理。 外观是一个能为子系统和客户提供简单接口的类。当正确的应用外观，客户不再直接和子系统中的类交互，而是与外观交互。外观承担与子系统中类交互的责任。实际上，外观是子系统与客户的接口，这样外观模式降低了子系统和客户的耦合度。 我们可以看到：外观对象隔离了客户和子系统对象，从而降低了耦合度。当子系统中的类进行改变时，客户端不会像以前一样受到影响。 尽管客户使用由外观提供的简单接口，但是当需要的时候，客户端还是可以视外观不存在，直接访问子系统中的底层次的接口。这种情况下，它们之间的依赖/耦合度和原来一样。 * 外观模式是迪米特法则的一种体现。不和陌生人说话。 外观模式（Fa?ade pattern）涉及到子系统的一些类。所谓子系统，是为提供一系列相关的特征