HeadFirst設計模式 讀書筆記2

烘烤OO的精華
    認識工廠方法模式
       所有工廠模式都是用來封裝對象的創建
       工廠方法模式通過讓子類決定該創建的對象是什麼，來達到將對象創建的過程封裝的目的。
    組成元素
       創建者Creator類
          它定義了一個抽象的工廠方法，讓子類實現此方法制造產品。
          創建者通常會包含依賴於抽象產品的代碼，而這些抽象產品由子類製造。創建者不需要真的知道在製造哪種具體產品。
       產品類：工廠生產產品。對PizzaStore來說，產品就是Pizza。
    另一個觀點：平行的類層級
       爲什麼產品類和創建者類是平行的？都是抽象類，且都有許多具體的子類，每個子類都有自己特定的實現。
       NYPizzaStore所封裝的是關於如何製作紐約風味的比薩。工廠方法就是封裝這種知識的關鍵所在。
    工廠方法模式 
       定義了一個創建對象的接口，但由子類決定要實例化的類是哪一個。工廠方法讓類把實例化推遲到子類。
    要點：
       Creator是一個類，它實現了所有操作產品的方法，但不實現工廠方法。
       Creator所有的子類都必須實現這個抽象的factoryMethod方法。
       所有的產品必須實現一個共同的接口，這樣一來，使用這些產品的類，就可以引用這個接口，而不是具體類。
       ConcreteCreator實現了factoryMethod，以實際製造出產品。
       ConcreteCreator負責創建一個或多個具體產品，只有ConcreteCreator類知道如何創建這些產品。
    設計原則：要依賴抽象，不要依賴具體類。
    依賴倒置原則，不能讓高層組件依賴低層組件，而且不管高層或低層組件，2者都應該依賴於抽象。
       所謂高層組件，是由其他低層組件定義其行爲的類。
       例如，PizzaStore是個高層組件，因爲它的行爲是由比薩定義的。
    依賴倒置原則，究竟倒置在哪裏？
    避免OO設計中違反依賴倒置原則
       1變量不可以持有具體類的引用。
          如果使用new，就會持有具體類的引用。你可以改用工廠來避開這樣的做法。
       2不要讓類派生自具體類。
          如果派生自具體類，你就會依賴具體類，請派生自一個抽象（接口或抽象類）
       3不要覆蓋基類中已實現的方法。
          如果覆蓋基類已實現的方法，那麼你的基類就不是一個真正適合被集成的抽象。基類中已實現的方法，應該由所有的子類共享。
    抽象工廠模式
       提供一個接口，用於創建相關或依賴對象的家族，而不需要明確指定具體類。
    比較工廠方法和抽象工廠。。。    要點1：
       所有的工廠都是用來封裝對象的創建。
       簡單工廠，雖然不是真正的設計模式，但仍不失爲一個簡單的方法，可以將客戶程序從具體類解耦。
       工廠方法使用集成：把對象的創建委託給子類，子類實現工廠方法來創建對象。
       抽象工廠使用對象組合：對象的創建被實現在工廠接口所暴露出來的方法中。
       所有工廠模式都通過減少應用程序和具體類之間的依賴促進松耦合。
       工廠方法允許類將實例化延遲到子類進行。
       抽象工廠創建相關的對象家族，而不需要依賴它們的具體類。
       依賴倒置原則，知道我們避免依賴具體類型，而要儘量依賴抽象。
       工廠是很有爲例的技巧，幫助我們針對抽象編程，而不要針對具體類編程。

獨一無二的單件模式：用來創建第一無二的，只能有一個實例的對象的入場券。
    單件模式
       確保一個類只有一個實例，並提供一個全局訪問點。
    要點
       單件模式確保程序中一個類最多隻有一個實例。
       單件模式也提供訪問這個實例的全局點。
       在Java中實現單件模式需要私有的構造器，一個靜態方法和一個靜態變量。
       確定在性能和資源上的限制，然後小心地選擇適當的方案來實現單件，以解決多線程的問題(我們必須認定所有的線程都是多線程的)
       如果不是採用第五版的java2，雙重檢查枷鎖實現會失效。
       小心，你如果使用多個類加載器，可能導致單件失效而產生多個實例。
       如果使用JVM1.2或之前的版本，你必須建立單件註冊表，以免垃圾收集器將單件回收。

這些絕密文件的投遞箱已經促成了間諜工業的革命。我只要把需求丟進去，就有人會消失，政府一夕之間改朝換代，而我的乾洗衣物也好了。我不必管何時何地或者如何完成，反正就是完成了。
    在本章，我們把封裝帶到一個全新的境界:把方法調用封裝起來。
    加載調用者
       客戶創建一個命令對象。
       客戶利用setCommand將命令對象存儲在調用者中。
       稍後……客戶要求調用者執行命令。請注意：一旦命令被加載到調用者，該命令可以被使用並丟棄，或者可以被保留下來並使用許多次。
    餐廳應用到命令模式的相應名稱
       女招待   Invoke
       快餐廚師   Receiver
       orderUp()   execute()
       訂單   Command
       顧客    Client
       takeOrder()   setCommand()
    命令模式
       將“請求”封裝成對象，以便使用不同的請求、隊列或者日誌來參數化其他對象。命令模式也支持可撤銷的操作。
       命令對象將動作和接收者包進對象中。這個對象只暴露出一個execute()方法，當此方法被調用的時候，接收者就會進行這些動作。    NoCommand對象是一個空對象的例子。當你不想返回一個有一一的對象時，空對象就很有用。
       客戶也可以將處理null的責任轉移給空對象。
    命令模式的更多用途
       隊列請求
          命令可以將運算快打包（一個接受者和一組動作），然後將它傳來傳去，就像是一般的對象一樣。
       日誌請求
    要點
       命令模式將發出請求的對象和執行請求的對象解耦。
       在被解耦的兩者之間是通過命令對象進行溝通的，命令對象封裝了接受者和一個或一組動作。
       調用者通過調用命令對象的execute發出請求，這會使得接收者的動作被調用。
       調用者可以接受命令當參數，甚至在運行時動態地進行。
       命令可以支持撤銷，做法是實現一個undo方法來回到execute被執行前的狀態。
       宏命令是命令的一種簡單的延伸，允許調用多個命令。宏方法也可以支持撤銷。
       實際操作時，很常見使用聰明命令對象，也就是直接實現了請求，而不是將工作委託給接收者。
       命令也可以用來實現日誌和事務系統。