對GoF《設計模式》等面向物件設計的經典書籍的吐槽。分散在各文章中的吐槽可能被我刪除。

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不敢使用控制反轉這個術語了（本來穿衣服是正常的，裸體太流行了，我不敢穿衣服出門。嗯，就是這種趕腳。）