毕老师说：装饰模式比继承要灵活，避免了继承体系的臃肿，而且降低了类与类之间的关系。两者之间还有没有更全面点的区别所在呢？或者有更具体的说法呢

我觉得如果我们去装饰一个类的话,是出于想增强这个类的某个或某些功能的目的,
显然装饰更具有针对性,,如果用继承,虽然可以实现目的,,但是继承附带的有很多我们
不需要的元素,,,这样让增个体系就显得臃肿了,,,

装饰模式 VS 继承
装饰模式 继承
用来扩展特定对象的功能 用来扩展一类对象的功能
不需要子类 需要子类
动态地 静态地
运行时分配职责 编译时分派职责
防止由于子类而导致的复杂和混乱 导致很多子类产生，在一些场合，报漏类的层次
更多的灵活性 缺乏灵活性
对于一个给定的对象，同时可能有不同的装饰对象，客户端可以通过它的需要选择合适的装饰对象发送消息。 对于所有可能的联合，客户期望
很容易增加任何的 困难

装饰模式和继承都可以增强类的功能。
    装饰模式：通过某种方法将被装饰的类的对象传入进该类，通常是在构造方法中传入。然后，再在类中写增强功能的方法，这些方法的内部，使用传入的被装式的对象的方法去实现的。
    继承模式：如果需要对哪个类的方法的功能进行增强，那么就继承该类。并对要增强的方法进行重写，这样就可以实现方法功能的增强。

   它们都可以对类的功能进行增强，那么它们有什么区别呢？在IO流中，比如很多流我们都可以给它们加上缓冲的功能，那么如果我们使用继承的话，我们将会给每一个要增强的类都要写一个子类，这样我们就要写很多的子类。因此就很麻烦，做了很多重复的工作。如果用装饰模式的话，在构造方法中传入流的基类，我们知道流的基类就只有四个，也就是说，我们最多只用写四个装饰类，就可以给继承了这四个类的所有的基础进行某一方法的功能增强。比如IO流中的BufferedReader，BufferedInputStream,BufferedOutputStream,BufferedWriter,这四个类都是对流进行缓冲的增强。因此这样我们就可以省下不少的重复的工作，也少了很多类。

装饰模式：通过某种方法将被装饰的类的对象传入进该类，通常是在构造方法中传入。然后，再在类中写增强功能的方法，这些方法的内部，使用传入的被装式的对象的方法去实现的。
继承模式：如果需要对哪个类的方法的功能进行增强，那么就继承该类。并对要增强的方法进行重写，这样就可以实现方法功能的增强。
在IO流中，比如很多流我们都可以给它们加上缓冲的功能，那么如果我们使用继承的话，我们将会给每一个要增强的类都要写一个子类，这样我们就要写很多的子类。因此就很麻烦，做了很多重复的工作。如果用装饰模式的话，在构造方法中传入流的基类，我们知道流的基类就只有四个，也就是说，我们最多只用写四个装饰类，就可以给继承了这四个类的所有的基础进行某一方法的功能增强。比如IO流中的BufferedReader，BufferedInputStream,BufferedOutputStream,BufferedWriter,这四个类都是对流进行缓冲的增强。因此这样我们就可以省下不少的重复的工作，也少了很多类。----------引用他人总结，希望有所帮助，共同学习进步

装饰模式和继承都可以增强类的功能。
    装饰模式：通过某种方法将被装饰的类的对象传入进该类，通常是在构造方法中传入。然后，再在类中写增强功能的方法，这些方法的内部，使用传入的被装式的对象的方法去实现的。
    继承模式：如果需要对哪个类的方法的功能进行增强，那么就继承该类。并对要增强的方法进行重写，这样就可以实现方法功能的增强。

   它们都可以对类的功能进行增强，那么它们有什么区别呢？在IO流中，比如很多流我们都可以给它们加上缓冲的功能，那么如果我们使用继承的话，我们将会给每一个要增强的类都要写一个子类，这样我们就要写很多的子类。因此就很麻烦，做了很多重复的工作。如果用装饰模式的话，在构造方法中传入流的基类，我们知道流的基类就只有四个，也就是说，我们最多只用写四个装饰类，就可以给继承了这四个类的所有的基础进行某一方法的功能增强。比如IO流中的BufferedReader，BufferedInputStream,BufferedOutputStream,BufferedWriter,这四个类都是对流进行缓冲的增强。因此这样我们就可以省下不少的重复的工作，也少了很多类。
http://blog.sina.com.cn/s/blog_7f71be7b0100xbjx.html,百度一下,你就知道

装饰模式 VS 继承
装饰模式                继承
用来扩展特定对象的功能 用来扩展一类对象的功能
不需要子类              需要子类
动态地                  静态地
运行时分配职责          编译时分派职责
防止由于子类而导致的复杂和混乱 导致很多子类产生，在一些场合，报漏类的层次
更多的灵活性            缺乏灵活性

装饰模式应用场景举例：

“K哥，我老婆说要我和她一块回去见家长，她还说她父亲大人主动要和我多喝几杯，我该怎么办啊？”GG很着急的对自己的好朋友K说道，“晕，老婆？你们发展的也太快了吧，不过还是恭喜喔”K带着调侃的语气说道，“不过要去见家长这事情确实需要慎重的”，“按照惯例，既然对方主动的提出邀请，而且她父亲大人都说要和你小子多喝几杯，这是非去不可的了；其实也没什么，有些心理准备就行了，我们相信GG！”K继续调侃的说道，“不过，要注意形象:-O”，“具体要以什么形象出现呢？”GG问道，“这个你问我？我问谁啊？干脆我代你去算了”，“我是说认真的啊”GG有些着急，“这主要看你要给对方什么印象了啊”K有些认真的说道，“具体什么印象呢？”GG问道，“一般而言，首要的是必须让对方父母知道你很爱他们的女儿；其次：年轻人都是要有活力的，开朗而阳光；再次：要给对方家长自己很上进的印象:-O”K一脸认真的说道，“哈哈，K哥就是K哥，果然不愧是情场老大啊”，“那我具体应该穿什么呢？”GG接着问道，“牛仔裤是一定要穿的，你平时穿的那条天蓝色牛仔裤就很棒，至于上衣忙，你现在白色的衬衫就很不错的，别忘了头发要干净，牙齿要洁白，尽量的保持你单纯的傻傻的笑容^_^”，GG这么麻烦的问题被K三加五除二解决掉，GG兴奋的说：“老大，我爱死啦！”

装饰模式解释：

装饰（ Decorator ）模式又叫做包装（Wrapper）模式。通过一种对客户端透明的方式来扩展对象的功能，是继承关系的一个替换方案。

这是网上找的，感觉很靠谱了。

装饰设计模式和继承的区别？
Writer
|--TextWriter.
|--MediaWriter
发现可以形成体系，就是无论操作什么数据，但都是操作数据，可以抽取。
操作数据的效率有些低，为了提高这个操作效率，
使用缓冲技术。通过面向对象三个特点中的继承，发现可以继承完成功能的增强。
那么对具体的功能对象进行子类的扩展。
形成了一下的体系。

Writer
|--TextWriter.
   |--BufferedTextWriter
|--MediaWriter
   |--BufferedMediaWriter
该体系是完全可以应用的。
但是一点不太爽，当该操作数据的体系中如果出现了新的功能对象。
Writer
|--TextWriter.
   |--BufferedTextWriter
|--MediaWriter
   |--BufferedMediaWriter
|--DataWriter---新的功能对象。
   |--BufferedDataWriter
如果后期出现了象DataWriter这样新的功能对象时，为了提高该对象的操作效率，
该对象也需要有一个子类带有缓冲技术。
导致每出现一个新功能子类，该子类都要有一个带缓冲技术的子类。
对于扩展较为麻烦。而且让这个继承体系因为不断扩展而变得非常臃肿。
需要对该体系进行优化。
以前是让每一个功能对象都具备缓冲技术。
现在可不可以单独定义一个缓冲技术对象，要缓冲谁，就把谁传进来即可。
class BufferWriter
{
BufferWriter(Writer w)
{
  
}
/*
BufferWriter(TextWriter tw)
{

}
BufferWriter(MediaWriter mw)
{
  
}
*/
}
将缓冲技术封装成对象后，那么每一个功能对象就没有必要在定义带有缓冲技术的子类对象了。
体系就变成了
Writer
|--TextWriter.
|--MediaWriter
|--DataWriter
|--BufferWriter
即具备了缓冲功能，又优化了继承体系。
这种优化方式，很爽。可以解决功能增强问题，并比继承更有灵活性。降低了继承体系的复杂性。
为了方便于以后继续使用该优化方式，就给其起了个名字：装饰设计模式。
要记住，装饰类通常和被装饰类都所属于同一个体系。或者同一个接口。




上面的解释的满好理解的