walker...to the next step

无数设计书都叫嚣着这个标题，是为什么呢？

我觉着是因为大多数OO语言里，继承关系是不能在运行时动态改变的，但composition就可以啊，君不见那么多的Java getters/setters。

但如果继承关系能在运行时改变呢？？比如Python这样的，且不说把基类换掉这种极端做法了，就说运行时可以override父类方法，我觉得就避免了Java中继承带来的问题啊。这样的话，Strategy模式还有意义么？有么？？没有么？？

说的抽象一点，如果语言本身不够灵活，你就只能利用它有限的一点灵活度，来尽量避免一些僵硬的设计。但如果语言足够灵活呢？我倒不是说这一定是好事。因为语言灵活，实现一个设计就会有好多灵活的方案，尤其像老潘这样喜欢玩儿数据和代码互换的，准保写出代码来让人丈二和尚。

所以说Java的方案是：语言僵死，然后拿一堆设计模式来进补。。。这样倒也好，适合工业大规模开发哈。但这样的话Java程序员就特别容易把事情想死，以为天下就只有这一种办法了。所以如果你是个Java程序员，你一定要小心脑电路栓塞或者冠状思想硬化这样的毛病。我见过的不在少数。

我现在特别庆幸我是先学动态语言，后学设计模式。。。

总感觉Decorator模式像SICP里面讲的那个closure（数学意义上的closure），尤其是painter那一节。

Decorator们被用来“修饰”一些对象的行为，或者说给一些对象扩展功能。这本身不新鲜。重要的是它们进行扩展的方式：它们本身与这些被修饰/被扩展对象是同一类型——一般是共同实现某个接口或继承某个超类；一般来说它们的构造函数里接受一个和它们同类型的对象，并“修饰”之。修饰的方式一般是override某个方法，在此方法中调用被修饰对象的overriden方法并对其行为添油加醋，形成新的行为。

这里面一个非常关键的思想，就是被修饰对象经修饰以后，成为了一个新的对象，仍然属于“同一对象族系”。于是这个对象可以继续被修饰。。。靠，这明明就是closure思想嘛：一组对象，其上定义的一组操作的返回值仍然是同类型对象，可继续将同一组操作应用于其上。所以这些操作可以任意组合，形成各种各样不同的效果。数学中的例子比如实数集合和四则运算操作。

Decorator模式的典型例子就是Java标准库里的reader/writer及input/output stream系列。