(1) 編譯和運行本章中的JabberServer和JabberClient程序。接著編輯一下程序，刪去為輸入和輸出設計的所有緩沖機制，然後再次編

本章要向大家介紹重要但卻並不是那麼傳統的“范式”（Pattern）程序設計方法。在向面向對象程序設計的演化過程中，或許最重

在最開始，可將范式想象成一種特別聰明、能夠自我適應的手法，它可以解決特定類型的問題。也就是說，它類似一些需要全面認識某個問題的人。在了解了問題的方

或許最簡單的設計范式就是“單子”（Singleton），它能提供對象的一個（而且只有一個）實例。單子在Java庫中得到了應

《Design Patterns》一書討論了23種不同的范式，並依據三個標准分類（所有標准都涉及那些可能發生變化的方面）。這三個標准是：(1) 創

觀察器（Observer）范式解決的是一個相當普通的問題：由於某些對象的狀態發生了改變，所以一組對象都需要更新，那麼該如何解決？在Smalltal

這個問題的本質是若將垃圾丟進單個垃圾筒，事實上是未經分類的。但在以後，某些特殊的信息必須恢復，以便對垃圾正確地歸類。在最開始的解決方案中，RTTI

《Design Patterns》書內所有方案的組織都圍繞“程序進化時會發生什麼變化”這個問題展開。對於任何設計來說，這都

這樣便引出了面向對象程序設計時一條常規的准則，我最早是在Grady Booch那裡聽說的：“若設計過於復雜，就制作更多的對象&rdqu

上述設計方案的一個問題是仍然需要一個中心場所，必須在那裡知道所有類型的對象：在factory()方法內部。如果經常都要向系統添加新類型，facto

走到這一步，接下來該考慮一下設計方案剩下的部分了——在哪裡使用類？既然歸類到垃圾箱的辦法非常不雅且過於暴露，為什麼不隔離那

上述設計方案肯定是令人滿意的。系統內新類型的加入涉及添加或修改不同的類，但沒有必要在系統內對代碼作大范圍的改動。除此以外，RTTI並不象它在Rec

記住多形性只能通過方法調用才能表現出來，所以假如想使雙重派遣正確進行，必須執行兩個方法調用：在每種結構中都用一個來判斷其中的類型。在Trash結構

接下來，讓我們思考如何將具有完全不同目標的一個設計范式應用到垃圾歸類系統。對這個范式，我們不再關心在系統中加入新型Trash時的優化。事實上，這個

本章的各種設計方案都在努力避免使用RTTI，這或許會給大家留下“RTTI有害”的印象（還記得可憐的goto嗎，由於給人印象

從表面看，由於象TrashVisitor.java這樣的設計包含了比早期設計數量更多的代碼，所以會留下效率不高的印象。試圖用各種設計方案達到什麼目

如果您有C或C++的經驗，那麼最開始可能會對Java控制文本的能力感到懷疑。事實上，我們最害怕的就是速度特別慢，這可能妨礙我們創造能力的發揮。然而

對於本書每一個完整的代碼列表（不是代碼段），大家無疑會注意到它們都用特殊的注釋記號起始與結束（//:和///:~）。之所以要包括這種標志信息，是為

盡管對涉及文字處理的一些項目來說，前例顯得比較方便，但下面要介紹的項目卻能立即發揮作用，因為它執行的是一個樣式檢查，以確保我們的大小寫形式符合&l

第11章介紹了Java 1.1新的“反射”概念，並利用這個概念查詢一個特定類的方法——要麼是由所有