对GoF《设计模式》等面向对象设计的经典书籍的吐槽。分散在各文章中的吐槽可能被我删除。
- 2.1.5 抛弃依赖倒置原则
- 模板方法模式
GoF在这个模式的介绍中,提到的
IoC、好莱坞法则和钩子,yqj2065认为他们是在找抽。
关于这个模式,我在考虑用不用脑残的、包含几个明显实现步骤的例子,脑残例子便于介绍子类对待父类方法的5种形式,讨论如何有效地控制和合理地使用实现继承。[空方法的作用],讲一下Java的MouseAdapter这种让做事情比较方便的器,做便器?难听。
“模板方法非常基本,它们几乎可以在任何一个抽象类中找到。”
到底是1有代表性,还是n有代表性呢?
我个人喜欢1到多。所以,“
策略非常基本,它们几乎可以在任何一个抽象类中找到。”
- 3.3 桥接模式(4.2)
这个模式,我认为GoF没有研究清楚。桥接模式的本质——嵌套的行为参数化、或者说“在策略中提供策略”。
他们将两次策略视为一体,使用“抽象与它的实现”描述。在我们的例子中,一连串的策略嵌套,他们会说成抽象 、它的实现、实现的实现、实现的实现的实现...
Martin Fowler在文章1中挖苦道:【几位轻量级容器的作者曾骄傲地对我说:这些容器非常有用,因为它们实现了控制反转。这样的说辞让我深感迷惑:控制反转是框架所共有的特征,如果仅仅因为使用了控制反转就认为这些轻量级容器与众不同,就好象在说"
我的轿车是与众不同的,因为它有四个轮子"。】,其实,应该算太给他们面子了。
从完成IServer初始化的角度看,God能够完成Spring目前的工作(Spring作为庞大的框架,也其他用途),所以将God也作为注入工具。
★Spring隐式注入,God显式注入。
关键在于,Spring的DI,也和God一样,仅仅是一个被调的工具/ 库。按照我关于框架的定义,你一个框架,应用程序员使用时怎么地也要编写一个@Override方法,
所以,Spring的DI,完全和框架、控制反转IoC,一点关系都没有。它完全是一个自行车,只有两个轮子。
- 何谓控制反转
拜托,在我的术语表中没有
控制反转(Inversion of Control,英文缩写为IoC)这个垃圾术语,我不知道它是什么东西。
yqj2065不敢使用
控制反转这个术语了(本来穿衣服是正常的,裸体太流行了,我不敢穿衣服出门。嗯,就是这种赶脚。)