下面全是個人理解。
Head First 第一章中講的策略模式，我覺得是所有設計 模式中最基本的。
它提到了幾個設計原則：都是我們平常編程中用到的。
1：將應用中變化之處和，不需要變化之處分離出來。這其實就很類似，封裝的定義；
2：面向接口編程，而不是面向實現編程。想想我們在做web項目時，servie層，以及dao層，都是面向接口編程的，爲的就是如果換掉數據庫實現，那麼在action層，我們就不需要更改代碼了。
3：少用繼承，多用組合。我們在做web項目時，service實現中，包含有dao的引用 ，其實就是組合。而且這種組合是高內聚，低耦合的。因爲我們可以在運行時，指定特定的dao實現。這也是一種面向接口編程。
Head First 第一章針對Duck（鴨子）類 做了一個探討。
Duck 書中定義的是抽象類，它有quack() 呱呱叫的方法，以及swim() 游泳的方法，還有一個抽象方法display() 外觀方法。每種鴨子，都繼承Duck類，自己實現display方法。
需求1：現在在Duck中增加一個方法fly()方法，由於 使用的繼承，那麼所有實現了Duck的子類 ，都有fly方法，就是會飛。但是問題來了，由於使用的是繼承，會導致有些 不會飛的鴨子也擁有這個方法，有的人說，會飛就會嘛，有什麼 關係，但是 你自己不覺得很怪嗎？還有人覺得，我讓不會飛的鴨子重寫fly()方法，讓它什麼 都不做不就可以了嗎？咋一想，好像是這麼一回事，但是，如果有這麼 一種鴨子，不會飛也不會叫還不會游泳，那麼 你完蛋了，這個時候，你要檢查所有的子類了，看看它們的所有方法，是否滿足條件了、
所以繼承帶來的問題就是，子類繼承了不必要的一些行爲。
這個時候，我想要了接口，把鴨子的每種行爲定義成一個接口，讓那麼需要有這些行爲的鴨子去實現它，就可以了。哎，仔細想想，好像可以。
需求2：假如有三個子類分別實現了Duck，按照上面的想法，定義一個fly方法，quack()，swim()。那麼這三個子類，如果三個子類fly,swim,quack的實現都是一樣，那麼 這樣 代碼是不是重複寫了很多呀！！現在只是三個子類，如果30個呢，想想。
需求3：講到這裏，Head First 講到了最後的解決方案，其實也是用到了接口，只是和上面不一樣，它是定義一組接口行爲，只是它由一組專門實現接口行爲的類來實現，而不是由鴨子類來實現，我們只需要在Duck類中定義一些鴨子類的行爲，具體的實現，在運行時，自己定義。這樣，即使再增加一些行爲，也只需要在Duck類中定義這些行爲，具體的實現，就不關鴨子的事情了。