Fatory Template Stategy --Head First Design Pattern讀書筆記(三)

     雖然最近項目比較緊，但是仍堅持每天看幾頁Head First Design Pattern（short for HFDP），可以說是受益良多，剛剛看過Template Pattern，其中有一個特殊的環節就是FireSide Chat（HFDP的特色，沒有新的Pattern講述完畢，就會拿出類似的Patterns做對話，相當的不錯）。這一次是Template vs Strategy compare methods。而factory 也和template也有很大相似的地方

    先分别說：

    一、Template method Patten  -- Encapsulating Algorithms

    這是我們最為熟悉和常用的一個設計模式，特别是用于架構的建構中，Template可謂功不可沒，最為鮮明的例子：Struts。Template Method Pattern defines the skeleton of an algorithm in a method,deferring some steps to subclasses.Template method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.

    一出現了Struts字樣，就會發現Template method 一下就親切了不少（其實這樣說并不準确，實際上是Servlet實作了這一模式，而Struts的ActionServlet就是一個标準的Servlet實作），這樣在我們平時的工作過程中，Template一下變得無處不在，不管什麼項目，隻要上點規模，肯定是要寫個基礎算法的基類，要不不行就上架構，OK，你已經在使用Template method pattern了，還有HFDP中還告訴我們java.io的read()方法 Array的sort() JFrame Applet都活躍着Template的影子，也就是說有一個固定的算法、一些可複用的方法這就構成了一個Template。Template是實作了經典好萊塢原則Don't call me,i'll call you的最佳範例，在好萊塢原則下，允許low-level component将自己hook到一個系統中，并且有High-level component決定他們什麼時候被使用和怎樣被使用。

    二、Strategy method pattern

    做為HFDP的開篇模式，Strategy的任務似乎更多一些，不但要讓讀者更為清晰的認識到使用模式的作用和必要性，還要介紹若幹基本問題，而其通過幾隻不同的鴨子來闡述這一模式讀者來說顯得更生動而印象深刻。

     是以在認識Strategy的過程中我們首先認識的是3個OO design Principle

     1.Identify the aspects of your application that vary and separate them from what stays the same 鴨子是會變的，它們今天會叫、明天可能就會飛，它們會變成怎樣我們不知道，但是我們有了這個設計原則就你要變就分開變，怎麼變我們也不怕不怕。

    2.Program to an interface, not an implementation 最典型的就是Java的上溯造型了，看Think in Java最先學到的就是這個。

    3.Favor composition over inheritance 看來這第一章的資訊量真的是大哦，composition，這裡就引出了一個OO的兩個基礎模式composition和aggregation，于是去google，發現了這個：http://www.visualcase.com/kbase/associations.htm，重新了解下assosiation,compostion,aggregation之間的關系和差別。下面介紹了這些東西，猛然發現現在寫文字也有職業病的困擾，這種介紹方式很像一個内部類的實作 ：（。明白了composition，這個原則就很清晰，慎用繼承而使用composition。3個原則加在一起，Strategy的雛形也就差不多了：Strategy模式将可能會變化的部分封裝起來與其他對象分離，并使用接口來調用他們而不去關心具體實作，這個過程都不是繼承而來而是組合了所有接口。

     assosiation表明對象和對象之間有關系，學生去學校讀書、學生選擇課程，學生和學校、課程之間就有了關系。每個對象被稱為roles，每個roles都由name、multiplicity、navigability、type幾個屬性構成

     Multiplicity:指定roles之間有多少對象可以參與到這個relationship中來，學校有多個學生，而學生隻有一個學校。

     Navigability:每個roles都有arrow（在UML關系圖中）指定他們的Navigability，展示classes在關聯關系中維護關系的職責，可以通過學校知道有什麼學生在學校讀書，也就是defined by the navigability of the assosiation。

     type:可以有三種：assosiation,composition,aggregation，

          A.assosiation就是上面說到的關系

          B.composition 指明對象的從屬關系，多邊形包括多個點，多邊形不在了，點也不複存在。

          C.aggregation 和composition類似，也表示對象的從屬關系，但是沒有composition那麼嚴格，訂單是包含多個産品，但是訂單不存在産品卻仍然存在。

     經曆了3個設計原則的介紹，才把這個Strategy引出來，足見Strategy有多牛：The Strategy Method Pattern defines a family of algorithms,encasulates each one,and makes them interchageable.Strategy lets the algorithm vary independently from clients that use it.

     最常見的例子：Spring的DI，在使用一個Spring的Bean的時候就是先來個composition+setter method。

    三、Factory

     已經在我的上一篇讀書筆記中提到很多了，是以這裡就不詳細說，Factory就是定義了對象建構的超類。但是和本文有關的是Abstract Factory，它不但建構了對象，還在建構的同時定義了一些固定的算法。

     比較：Template、Stategy、Factory

     狂多的東西都需要比較着來看，剛是合成、聚合和關聯比較，現在是它們3個，真的很亂，特别是Factory還經常和Template混用，但是還是有些差别，Template比較單純，僅僅是定義了算法的過程，而且是單純的繼承，Abstract Factory是指定了一定的算法去建構對象。

     Template和Strategy，個人認為，他們的比較就可以想Struts1和Struts2（webwork2）比較一樣，一個使用了繼承，一個使用了接口，這樣對Template可能不公平，因為Struts令人诟病很深的就是這個繼承，但是它仍然那麼有生命力，Struts的ActionServlet定義了一個完成doget()請求的處理方式，也就是這個處理方式算法的骨架，然後由我們去實作具體的不同的業務邏輯，并且Template模式中子類是可以任意使用父類中的公共方法的，減少了代碼重複。而WebWork的execution就是那麼一個接口，如何實作你說了算，也就是那個封裝和分離可能會變化的東西的原則，Webwork允許使用它的用戶端來決定算法的變化。