装饰模式

 

今天讲的是个特别有意思的一堂课先讲了流，主要讲的是字符流读取流和写入流具体如下

Java 流在处理上分为字符流和字节流。字符流处理的单元为 2 个字节的 Unicode 字符，分别操作字符、字符数组或字符串，而字节流处理单元为 1 个字节，操作字节和字节数组。

其下close()是读取字符其实用的是window系统的功能，就希望使用完毕后，进行资源的释放。

字节流可用于任何类型的对象，包括二进制对象，而字符流只能处理字符或者字符串； 2. 字节流提供了处理任何类型的IO操作的功能，但它不能直接处理Unicode字符，而字符流就可以

二、后来又讲了装饰模式通过超级玛丽这个小游戏吸引了我们的兴趣来讲解了下装饰模式，又通过MP3、存储器这个例子使得我们有了更深的了解

装饰模式我总结了以下四个特点：

（1）装饰对象和真实对象有相同的接口。这样客户端对象就可以以和真实对象相同的方式和装饰对象交互。
（2） 装饰对象包含一个真实对象的索引（reference）
（3） 装饰对象接受所有的来自客户端的请求。它把这些请求转发给真实的对象。
（4） 装饰对象可以在转发这些请求以前或以后增加一些附加功能。这样就确保了在运行时，不用修改给定对象的结构就可以在外部增加附加的功能。在面向对象的设计中，通常是通过继承来实现对给定类的功能扩展。

其实在一个对象的外围创建一个称为装饰器的封装，动态地给这个对象添加一些额外的功能。在一个对象的外围创建一个称为装饰器的封装，动态地给这个对象添加一些额外的功能。以对客户端透明的方式扩展对象的功能。
装饰器模式又称为包裹模式(wrapper),因为一个具体装饰器都将下一个具体装饰器或具体构件类包裹起来。如有三个装饰器类Decorator1, Decorator2, Decorator3,它们的典型的创建过程为new Decorator1(new Decorator2(new Decorator3(new ConcreteComponent()))).
装饰器角色持有一个构件对象的实例，并实现了抽象构件的接口。每一个接口的实现都是委派给所持有的构件对象，并增加新的功能。
装饰器与继承的目的都是扩展对象的功能，但装饰器提供了比继承更大的灵活性，可以动态的决定是“粘上”还是“去掉”一个装饰。 通过使用不同的具体装饰类和这些类的排列组合，可以创建出很多不同行为的组合。装饰器比继承关系使用更少的类，但比继承关系使用更多的对象，更多的对象会使查错变得更困难，特别是这些对象看上去很像的时候。
模式的简化:
简化必须注意两点：
    一个装饰器类的接口必须与被装饰的类的接口相容。
    尽量保持Component作为一个“轻”类。
    Component类的职责在于为各个具体装饰器类提供共同的接口,而不是存储数据，所以不要把太多的逻辑和状态放在Component类里面。
    省略Component接口,只有一个具体的ConcreteComponent类,则Decorater经常作为ConcreteComponent的子类。