第一篇：最簡單的設(shè)計模式學(xué)習(xí)

最簡單的設(shè)計模式學(xué)習(xí)：Singleton模式

學(xué)習(xí)設(shè)計模式，自然從最簡單的模式入手，而最簡單的模式便是Singleton。所以第一篇就來所以說Singleton模式?？赐闓OF和Design patterns in Java的書，感覺Singleton雖然簡單，但是想寫出一個好的Singleton也不是一上來就能寫出來的。

Singleton模式的用處自然是保證一個類只有一個唯一的實例。在建模中涉及到的只能有一個對象，例如Struts中的Action類就是一例。除此之外，Singleton還使得該對象只有一個全局訪問點。這就是SIngleton的作用。

說得比較抽象，我們來看一個簡單Singleton的C++和Java的代碼：

C++ Singleton模式：

類定義：

1.class Singleton

2.{

3.public:

4.static Singleton * Instance();

5.~Singleton();

6.7.private:

8.Singleton();

9.10.static Singleton * instance;

11.};

方法實現(xiàn)：

1.Singleton * Singleton::instance = 0;

2.3.Singleton::Singleton()

4.{

5.6.}

7.8.Singleton::~Singleton()

9.{

10.11.}

12.13.Singleton * Singleton::Instance()

14.{

15.if(instance == 0){

16.instance = new Singleton();

17.}

18.19.return instance;

20.}

Java Singleton模式：

1.public class Singleton {

2.3.private static Singleton instance;

4.5.public static Singleton getInstance(){

6.if(instance == null)

7.instance = new Singleton();

8.9.return instance;

10.}

11.12./** *//** Creates a new instance of Singleton */

13.private Singleton(){

14.}

15.}

通過上面的例子可以看出，Singleton的實現(xiàn)并不難，只要將構(gòu)造函數(shù)訪問域設(shè)為私有，然后添加一個靜態(tài)引用和一個獲得該應(yīng)用的靜態(tài)方法即可。其實在C++中定義一個全局靜態(tài)變量也可以達到這個效果，但是像Java這樣的語言就是能使用Singleton了。

上面的程序有一個問題，就是只能運行在單線程的環(huán)境下。為此我在C++上作了個實驗。首先#include。在SIngleton::Instance()函數(shù)中增加一個Sleep(1000)，程序如下：

1.2.3.4.5.6.7.8.9.Singleton * Singleton::Instance(){if(instance == 0){Sleep(1000);instance = new Singleton();}return instance;}

然后在主函數(shù)中創(chuàng)建兩個線程，程序如下：

1.static Singleton * s1 = 0, * s2 = 0;

2.3.DWORD WINAPI ThreadProc1(PVOID)

4.{

5.s1 = Singleton::Instance();

6.7.return 0;

8.}

9.10.DWORD WINAPI ThreadProc2(PVOID)

11.{

12.s2 = Singleton::Instance();

13.14.return 0;

15.}

16.17.int main(int argc, char* argv[])

18.{

19.DWORD threadID1;

20.DWORD threadID2;

21.22.CreateThread(NULL, 0, ThreadProc1, NULL, 0, &threadID1);

23.CreateThread(NULL, 0, ThreadProc2, NULL, 0, &threadID2);

24.25.Sleep(10000);

26.27.std::cout << s1 << “ ” << s2;

28.29.return 0;

30.}

這樣修改后在運行程序，打印出來的s1和s2地址就不是同一個地址了。結(jié)果如下： 0372D68 00372E68Press any key to continue

可見當(dāng)在多線程環(huán)境下使用這個Singleton就會出現(xiàn)創(chuàng)建不止一個實力的情況，所以我們需要給Singleton加鎖。請看下面的代碼。

C++ Singleton模式：

1.2.3.4.5.6.7.class Singleton{public:static Singleton * Instance();virtual ~Singleton();private:

8.Singleton();

9.10.static CMutex mutex;

11.static Singleton * instance;

12.};

1.Singleton * Singleton::instance = 0;

2.CMutex Singleton::mutex;

3.4.Singleton::Singleton()

5.{

6.7.}

8.9.Singleton::~Singleton()

10.{

11.12.}

13.14.Singleton * Singleton::Instance()

15.{

16.mutex.Lock();

17.18.if(instance == 0){

19.Sleep(1000);

20.instance = new Singleton();

21.}

22.23.mutex.Unlock();

24.25.return instance;

26.}

此外需要#include < afxmt.h>，并且在項目設(shè)置中要設(shè)置動態(tài)鏈接MFC庫。Java Singleton模式：

1.2.3.4.5.6.7.8.public class Singleton {private static Singleton instance;private static Object lock = Singleton.class;public static Singleton getInstance(){synchronized(lock){if(instance == null)

9.instance = new Singleton();

10.11.return instance;

12.}

13.}

14.15./** *//** Creates a new instance of Singleton */

16.private Singleton(){

17.}

18.}

運用加鎖就可以解決在多線程環(huán)境下使用Singleton模式所帶來的問題了。原文出處：中軟卓越http://http://

第二篇：哪些設(shè)計模式最值得學(xué)習(xí)

回想起來，這幾年在園子里發(fā)布的有關(guān)設(shè)計模式的隨筆都有一個共同的特點。那就是

Factory和Singleton居多，如果是系列的，也往往是從這兩個模式開始的。由于能夠堅持把《設(shè)計模式》中所有模式都寫完的非常少，所以基本上也很少見到有關(guān)其它模式的隨筆。這種情況也很好理解，因為《設(shè)計模式》這本書就是按照這個順序來的。最先講述的就是Abstract Factory模式，于是它排第一也無可厚非；排第二的Builder基本不太容易見到；第三的Factory Method由于也叫“Factory”所以往往和Abstract Factory放在一起，或者干脆就混淆了； 第四的Prototype也不是太容易見到；第五位的Singleton簡單易懂，易學(xué)易用。而再往后的模式，恐怕作者們就沒什么耐心學(xué)下去了……這可能就是為什么Factory和Singleton出現(xiàn)頻率如此之多的原因吧。

《設(shè)計模式》已經(jīng)出版超過15年了，到今天已經(jīng)不是什么新鮮的東西了，可以說正在由“絕招”慢慢向著“基本功”轉(zhuǎn)變著。然而，這種學(xué)習(xí)模式的方式方法卻實在令人擔(dān)憂。Abstract Factory在實際中并不常見，因為它需要你有兩套并行的繼承體系，需要對同一個抽象有多于一種的實現(xiàn)方式。這種復(fù)雜的系統(tǒng)可以說不是每個領(lǐng)域，每個開發(fā)人員都能遇到的。在某些特定的領(lǐng)域可能很常見，但是在大多數(shù)領(lǐng)域并不需要這么復(fù)雜的對象創(chuàng)建方法。這就造成了很多人“殺雞用宰牛刀”，用復(fù)雜的方式，解決不那么復(fù)雜的問題。后果是增加了不必要的復(fù)雜度，給系統(tǒng)維護增加了困難。

另一個模式Singleton，由于實現(xiàn)簡單，意圖“似乎”也很明顯。被很多人用來作為“優(yōu)化”的一種方式。通過這種方式來節(jié)省內(nèi)存空間，減少對象實例。但是單一實例本身就等同于全局變量，而全局變量在幾十年前就已經(jīng)被證明是“反模式”了，用另一種形態(tài)的全局變量來代替另一種形態(tài)的全局變量有什么好處么？問題在與，Singleton的“意圖”并不在于優(yōu)化，而是在于“妥協(xié)”。Singleton的目的在于保證對象有單一的實例，這是因為對象必須要有單一的實例，如果存在多個實例，可能會引發(fā)錯誤。也就是說，Singleton以犧牲程序的清晰

和可維護性，來達到保證程序正確的目的。這跟本就和優(yōu)化八竿子打不著，這完全是一種設(shè)計上的妥協(xié)，犧牲一些好處來獲取更大的好處。如果僅僅是為了節(jié)省幾個對象實例，而非程序的正確才使用Singleton，那就是丟了西瓜揀芝麻。況且節(jié)省那幾個實例也跟本就不可能對程序的性能有太大的影響（特殊領(lǐng)域除外）。

人的時間是有限的，23個模式也不是都那么常用，哪些模式才是最經(jīng)常用到的，才是最值得學(xué)習(xí)的呢？

第一梯隊：Iterator，Observer，Template Method，Strategy

Iterator：LINQ，foreach這不都是Iterator么。

Observer：MVC的核心，.NET中事件就是Observer。

Strategy：對同一個行為有不同實現(xiàn)的時候，如果考慮將行為的實現(xiàn)委托（不是.NET中的委托）給另一個類，那就用到了Strategy。通過這種方式，可以簡單的替換算法的實現(xiàn)類，來達到更換算法的目的。

class Foo

{

private IBar bar;

public Foo(IBar bar)

{

this.bar = bar;

}

public void DoSomething()

{

//some code

bar.DoWhatYouWant();

//some code

}

}

class A : IBar

{

public void DoWhatYouWant()

{

//do in A's way

}

}

class B : IBar

{

public void DoWhatYouWant()

{

//do in B's way

}

}

Template Method：一個算法的同一個步驟有不同的實現(xiàn)，通過繼承來實現(xiàn)。這種方式通過創(chuàng)建子類來改變算法的實現(xiàn)和行為。ASP.NET WebForm中Page的OnInit，OnLoad等事件，就是Template Method。

class Foo

{

public void DoSomething()

{

//some code

DoWhatYouWant();

//some code

}

protected abstract void DoWhatYouWant();

}

class A: Foo

{

protected override void DoWhatYouWant();

{

//do in A's way

}

}

class B: Foo

{

protected override void DoWhatYouWant();

{

//do in B's way

}

}

面向?qū)ο蟮囊粋€重要特點就是多態(tài)，也就是對于同一個動作有不同的行為。Strategry通過委托的方式，將一個算法的不同實現(xiàn)委托給其它類；Template Method通過繼承的方式，讓子類實現(xiàn)算法的可變部分，基類則處理算法的流程和不變部分。近年來組合優(yōu)于繼承的觀點已經(jīng)成為主流，因此Strategy的處境頻率相對高一些，但是Template Method在解決簡單問題的時候更好用，只要注意繼承層次不要太多（<=3）就好。

第二梯隊：Adapter，F(xiàn)acade，Decorator

Adapter：當(dāng)你需要使用第三方庫，但是又不想太依賴于它的API，以便于今后在需要時可以方便的切換到另一個庫的時候，你就需要在你的代碼和第三方API之間放置一個抽象層，也就需要用Adapter模式了。比如你想使用log4net，如果直接在代碼中到處引用log4net的API，將來有一天需要切換到另一個庫比如EntLib，你的改動量可就大了去了。如果在一開始就自己設(shè)計一個API，在代碼中使用自己的API，再用Adapter模式將log4net的API包裝到自己的API中，如果有一天想要切換到Entlib，只要為EntLib在寫一個Adapter就行了。對于IoC框架也是一樣的。不過需要注意的是，如果第三方庫的API接口非常龐大，使用Adapter就會很麻煩，因為你需要包裝太多的東西，那么使用Adapter可能就不是一個太好的主意?；蛟S謹(jǐn)慎考慮確定一個不太可能會變化的第三方庫更好一些。

Facade：基本上用于簡化API，隱藏細(xì)節(jié)，在一個系統(tǒng)中，高層模塊調(diào)用低層模塊時，如果低層模塊API比較復(fù)雜，而高層模塊并不需要這種復(fù)雜度，那么加一個Facade，可以簡化高層模塊使用API的難度。

Decorator：為一個類的行為增加行為，比如ASP.NET MVC中的Action Filter。第三梯隊：Command，State，Composite

Command：統(tǒng)一接口，Undo/Redo。

State：當(dāng)你的model有多種狀態(tài)，model的行為在每種狀態(tài)下并不一樣的時候，就需要用State。如果你有多個相似的Switch，那也可能意味著需要用State來代替Switch。

Composite：ASP.NET WebForm的Page和Control就是一個例子。

這些模式和分類只是憑我的感覺，并沒有任何實際的數(shù)據(jù)做支持，而我的感覺也只來源于我所接觸到的領(lǐng)域和代碼。希望同學(xué)們也可以提供自己接觸到的代碼中，最常見到和用到的模式。

第三篇：學(xué)習(xí)設(shè)計模式的一些感想

設(shè)計模式在編程中的應(yīng)用

我們在發(fā)現(xiàn)問題到解決問題這個過程中，常會發(fā)現(xiàn)很多問題是重復(fù)出現(xiàn)的，或是某個問題的變體，外在不同，而本質(zhì)相同，建筑學(xué)上如是，軟件行業(yè)也是，這些問題的本質(zhì)就是模式。有人說，設(shè)計模式并不是一日兩日能夠理解的，當(dāng)編程經(jīng)驗到了一定程度，便迫切的需要設(shè)計模式來完善自己的代碼、優(yōu)雅自己的設(shè)計，以及減少重復(fù)編碼，這句話也是蠻有道理的，以自己的親身經(jīng)歷來說，當(dāng)剛開始編程時，沒有一點設(shè)計理念，等到開設(shè)這門課以后再細(xì)讀理解，把里面的思想帶到自己的項目中，就會覺得有很多值得深思的地方。本文以我在以往項目中遇到的三個編碼問題來談?wù)剬W(xué)習(xí)設(shè)計模式的必要性。

一、代碼量激增、程序可維護性面臨挑戰(zhàn)

我想這樣的代碼我們從學(xué)習(xí)C語言就開始接觸，現(xiàn)在很多地方還在用，以后工作可能用的更多但是，大家都寫的東西，我們自己的優(yōu)勢在哪里呢？

1.過多的if?else判斷 if(type == 1){ //調(diào)用獲取信息方法1 } else if(type == 2){ //調(diào)用獲取信息方法2 ??.} else { //調(diào)用獲取信息方法7 } 這是我在做一個項目中看到的一段代碼，那個條件判斷非常之長，有7個條件分支，而且其他有些地方也有根據(jù)類型來做不同處理的情況。

2.多次載入資源（例如配置文件的讀?。?，引起資源損耗

public static String getProperty(String propKey)throws Exception...{ Properties prop = new Properties();InputStream propConfFile = Util.class.getClassLoader().getResourceAsStream(“configure.properties”);//載入propConfFile到prop中，從prop中獲取propKey的值，并將其返回 }

該段代碼是我以前在一個項目中寫的一段代碼，該段代碼用于讀取配置文件的屬性，但該段代碼是存在一些問題的，因為在每次獲取屬性時，它都重新載入資源，造成了資源的過多損耗。

3.過多依賴實現(xiàn)類

1）水果接口類—Fruit.java public interface Fruit { public void grow();}

2）水果的實現(xiàn)類—Apple.java、Strawberry.java //略

3）測試類—Test.java public class Test { public static void main(String[] args){ Fruit apple = new Apple();Fruit strawberry = new Strawberry();} } 在我們的項目中尚未采用Spring時，類似這樣的程序很多，與實現(xiàn)類的過度耦合是這段代碼存在的一個主要問題。

在我編碼的過程中，遇到的問題還有很多。不夠優(yōu)雅的代碼、過于僵硬的設(shè)計，等等，通過改進如上編碼來認(rèn)識學(xué)習(xí)設(shè)計模式給我們的編碼帶來的好處。

二、借“設(shè)計模式”之力沖出代碼包圍圈

如上的三段代碼，都是存在不少問題的，讓我們一一討論，通過在其中應(yīng)用設(shè)計模式，來優(yōu)化我們的這三段代碼，提高其擴展性和易維護性。

1.解決過多的if?else判斷問題

如果在一段代碼中，不少地方需根據(jù)某類型或狀態(tài)等做出不同的處理，那當(dāng)類型或狀態(tài)增加時，這些代碼將會過于僵硬，擴展性差，只有在各個分布了if?else的再增加一個else if，可維護性可想而知。設(shè)計模式中有一種模式可以解決該問題，即狀態(tài)模式。狀態(tài)模式給我們帶來的好處如下：

1）狀態(tài)模式需要對每一個對每一個系統(tǒng)可能取得的狀態(tài)創(chuàng)立一個狀態(tài)類（State）的子類，當(dāng)系統(tǒng)的狀態(tài)變化時，系統(tǒng)改變所選的子類。與一個特定的狀態(tài)有關(guān)的行為都被包裝在一個特定的對象里，而且當(dāng)需要增加新的狀態(tài)時，可以以子類的方式將它加到系統(tǒng)里，從而提高了易維護性和可擴展性；

2）由于每一個狀態(tài)都被包裝到了類里面，避免了使用過多的條件轉(zhuǎn)移語句。

下面我們對該例進行演示性的改進。我們可以定義一個類型接口，該類相當(dāng)于狀態(tài)模式中的狀態(tài)類。

public interface Type { /** * 獲取信息 */ public Object getInfo();/** * 獲取結(jié)果 */ public Object getResult();} 類型

1、類型2等可以實現(xiàn)該接口，代碼略：

2.解決過度資源損耗問題

在該例中，每次通過getProperty(?)方法獲取某屬性時，都會重新載入文件中的所有內(nèi)容，造成資源的不必要損耗。該設(shè)計模式中，對于此種情況，可以通過單例（Singleton）模式來優(yōu)化處理。import //略

public class PropertiesUtil...{ private static Map propertiesMap = null;public static String getProperty(String propKey)throws Exception...{ if(propertiesMap == null)...{ //當(dāng)propertiesMap為空時，載入文件，將其鍵值對放入propertiesMap中(略)} //在propertiesMap中獲得propKey屬性，并將值返回（略）} }

可以考慮實現(xiàn)單例模式的地方還有很多，例如：

1）對于計算機的外部資源打印機的情況，因只有一個Printer Spooler，為避免兩個打印作業(yè)同時輸出到打印機中，可考慮用單例模式實現(xiàn)。

2）Window的回收站在整個系統(tǒng)中只有唯一的一個實例，而且回收站自行提供自己的實例，回收站也是單例模式的應(yīng)用

3、解決過多依賴實現(xiàn)類問題

在該例的測試類Test.java中，通過Fruit apple = new Apple();來獲得對象，造成了程序過多的依賴實現(xiàn)類，與實現(xiàn)類過度耦合，學(xué)習(xí)設(shè)計模式后，我們可以考慮采用工廠模式來實現(xiàn),可對代碼進行如下改進：增加工廠類FruitGardener.java，該類的工廠方法如下： public static Fruit factory(String fruitType)...{ if(fruitType.equalsIgnoreCase(“apple”))...{ return new Apple();} else if(fruitType.equalsIgnoreCase(“strawberry”))...{ return new Strawberry();} else...{ return null;} }

增加了水果工廠類后，測試類也要做對應(yīng)修改，修改后的Test.java的main方法如下： Fruit apple = FruitGardener.factory(“apple”);Fruit strawberry = FruitGardener.factory(“strawberry”);

在進行了對應(yīng)修改后，測試類大大減少了對水果實現(xiàn)類的依賴，由直接new實現(xiàn)類變成了通過傳入字符串來獲得需要的實例，工廠模式應(yīng)用很廣泛，例如在現(xiàn)在紅得似火的spring也在不少地方用了工廠模式，它本身就是一個很大的bean工廠，不過它在代碼上進行了更大的改進，各實現(xiàn)類可以通過配置文件設(shè)置。

三、設(shè)計模式 –––– 由優(yōu)秀邁向卓越的階梯

從以上三個例子中我們可以看出，通過使用設(shè)計模式，優(yōu)化了我們的代碼。這樣的例子在我們?nèi)粘５木幋a過程中有很多，在我們剛開始學(xué)習(xí)編碼時，寫這樣的代碼還說得過去，但隨著經(jīng)驗的增長，我們需要更進一步，現(xiàn)有的設(shè)計模式給我們提供了解決大多數(shù)問題的好方案，當(dāng)然，在實踐的過程中，我們甚至可以探索出新的設(shè)計模式，來解決遇到的某類問題。

學(xué)習(xí)設(shè)計模式不是一蹴而就的，很多人嘆息設(shè)計模式似乎很不錯，然而在自己的編碼設(shè)計生涯中用得極少，我想主要原因是因為對設(shè)計模式的學(xué)習(xí)還不夠，還沒將其變成屬于自己腦袋里的東西，所以當(dāng)問題變著面孔出現(xiàn)時，認(rèn)識不到問題的存在，因為不能正確的分析問題、認(rèn)識問題，當(dāng)然也不可能很好的解決問題。

還未學(xué)習(xí)過設(shè)計模式或?qū)ζ渲跎俚某绦騿T們，努力學(xué)習(xí)設(shè)計模式吧，那將使你由一個優(yōu)秀的程序員(Coder)成為一個卓越的軟件設(shè)計師(Developer)。

第四篇：JAVA學(xué)習(xí)書籍- 設(shè)計模式

談到設(shè)計模式很多人多會推薦GOF 的那本，該書在Amzon上是五星級的推薦書籍。不過對于學(xué)習(xí)java 沒多久的、特別是java 初學(xué)者，我很不推薦這本書。主要是該書的例子基本都是C++的，很多細(xì)節(jié)沒有講述得足夠清楚。

我給大家推薦的第一本是閻宏博士的《Java 與模式》，它是第一本中國人自己寫的關(guān)于設(shè)計模式的書籍，寫的比較有趣，融合了很多中

華民族的文化和觀念，例子、類圖都比較多，且相對簡單！非常不錯的入門書籍――又是大塊頭哦！

其次我推薦Wiley 出版社出版的《Pattern In Java》一套三本，我才看了第一本，好像第二本不怎么樣，第三本還不錯！

第三本是中文翻譯版的關(guān)于多線程模式的（很難得的中文翻譯版）中國鐵道出版社2003 年出版的《Java 多線程設(shè)計模式》，將多線程模

式講得非常淺顯，配有大量的圖例，每章都有習(xí)題，最后有答案！我研究多線程模式就是由它開始的！

第四本，今年出版的Head First 系列的《Head First Design Pattern》，秉承Head First 系列圖書的優(yōu)點，大量的類圖、豐富的實例、有趣的注解，值得購買！

其次在J2EE 方向你可以研究閱讀Addison Wesley 2002 年出版的《Patterns of Enterprise Application Architecture》，眾多大腕的作品，講企業(yè)消息集成的！Sun 提供的《J2EE PATTERNS SL500》也很好！晚了推薦那一本Amzon 4 星半的《Holub on patterns》，大師的作品，提供了，很值得研究的例子，不過對上面四本不是很熟悉的讀者，最好不要讀它！可能會讓你比較累！

我學(xué)習(xí)設(shè)計模式經(jīng)過一段很曲折的路線，前前后后大約看了20 本，閻宏博士的《Java 與模式》我看了4 遍，還排除我第一次基本沒看

懂的看！記得研一時老師給我們講了GOF 的那本，作為選修課，我和它們計算機系的碩士、博士們一起，到最后一個班40－50 個人，不

超過3 個人明白，我也沒有明白任何一點（基礎(chǔ)差吧――主要我對C++語言一點都不了解），憑我不伏輸?shù)男愿?，我認(rèn)為我對java 語言理

解還可以，我就借了《Java 與模式》，結(jié)果還是基本沒看懂。很有幸的是讀研三時，聽過了上交大饒若楠老師關(guān)于Java OOP 語言的講座，我懂了組合書籍模式等三種設(shè)計模式后，對其它模式有了強烈的興趣和要征服它的愿望！工作后我買的第一本就是《Java 與模式》，第一遍花了2 個月研究了這個1000 多頁的大塊頭，后來第三遍15 天左右就可以搞定，筆記記了一大本！從此一發(fā)不可收拾。

選對書、埋頭研究。相信很快就會入門的！

學(xué)習(xí)Java 語言8 個簡單的部分，這只是我們研究Java 語言的開始！這些都懂了充其量一個java 程序員而已，后面的路很長很長！我們

可以繼續(xù)研究數(shù)據(jù)庫實現(xiàn)的源代碼、Servlet 服務(wù)器的源代碼、RMI、EJB、JNDI、面向方面編程、重構(gòu)、ANT 工具、Eclipse 工具、Spring

工具、JBoss、JOnAS、Apache Geronimo 等J2EE 服務(wù)器！研究了這些你可能會成為一個出色的J2EE Architecture！你可以繼續(xù)研究剖

析器、編譯器、JNODE（java 寫的操作系統(tǒng)）

第五篇：簡述為什么要學(xué)習(xí)設(shè)計模式

一、簡述為什么要學(xué)習(xí)設(shè)計模式？

答題要點：復(fù)用解決方案：通過復(fù)用已經(jīng)建立的設(shè)計，我為自己的問題找到了更高的起點并避免了繞彎路。我受益于學(xué)習(xí)別人的經(jīng)驗。我不必再為普通、重復(fù)的問題重新設(shè)計解決方案； 建立通用的術(shù)語：交流與協(xié)作都需要一個共同的詞匯基礎(chǔ)、一個對問題的共同觀點。設(shè)計模式在項目的分析和設(shè)計階段提供了一個通用的參考點；更高的分析和設(shè)計的視角：在問題上、在設(shè)計和面向?qū)ο蟮倪^程中，模式給你一個更高層次的視角。這樣的視角將你從“ 過早處理細(xì)節(jié)” 的暴政中解放出來。

二、選取你所熟悉的三個設(shè)計模式，詳細(xì)談?wù)勊鼈兊囊鈭D、設(shè)計動機和適用性 答題要點：Singleton：定義一個Instance操作，允許客戶訪問它的唯一實例。Instance是一個類操作。負(fù)責(zé)創(chuàng)建它自己的唯一實例。

Adapter：屬于結(jié)構(gòu)模式，動機：為復(fù)用而設(shè)計的類不能夠被復(fù)用的原因僅僅是因為接口與專業(yè)應(yīng)用領(lǐng)域所需要的接口不匹配，適用性：你想使用一個已經(jīng)存在的類，而它的接口不符合你的要求。

Template Method：意圖：定義一個操作中的算法骨架，而將一些步驟延遲到子類中，使得子類可以不改變一個算法的結(jié)構(gòu)即可重定義該算法的某些特定步驟。動機：模板方法使用抽象操作定義算法的先后順序，而子類將重新定義這些操作以提供具體的行為。適用性：一次性實現(xiàn)一個算法的不變的部分，并將可變的行為留給子類來實現(xiàn)各子類中公共的行為應(yīng)被提取出來并集中到一個公共父類中以避免代碼重復(fù)控制子類擴展

三、什么是IoC（Inversion of Control）、DIP（Dependency Inversion Principle）、Dependency Injection模式 ？舉例說明？

答題要點：控制反轉(zhuǎn)（Ioc）模式(又稱DI：Dependency Injection)就是Inversion of Control，控制反轉(zhuǎn)。在Java開發(fā)中，IoC意味著將你設(shè)計好的類交給系統(tǒng)去控制，而不是在你的類內(nèi)部控制。這稱為控制反轉(zhuǎn)。

IoC(Inversion of Control)是近年來興起的一種思想，不僅僅是編程思想。主要是協(xié)調(diào)各組件間相互的依賴關(guān)系，同時大大提高了組件的可移植性，組件的重用機會也變得更多。在傳統(tǒng)的實現(xiàn)中，由程序內(nèi)部代碼來控制程序之間的關(guān)系。我們經(jīng)常使用new關(guān)鍵字來實現(xiàn)兩組鍵間關(guān)系的組合，這種實現(xiàn)的方式會造成組件之間耦合(一個好的設(shè)計，不但要實現(xiàn)代碼重用，還要將組件間關(guān)系解耦)。IoC很好的解決了該問題，它將實現(xiàn)組件間關(guān)系從程序內(nèi)部提到外部容器來管理。也就是說由容器在運行期將組件間的某種依賴關(guān)系動態(tài)的注入組件中?？刂瞥绦蜷g關(guān)系的實現(xiàn)交給了外部的容器來完成。即常說的好萊塢原則“Don't call us, we'll call you”。

Ioc也有稱為DI(Dependecy Injection 依賴注射)，由Martin Fowler的一篇《Inversion of Control Containers and the Dependency Injection pattern》提出。DIP簡介（DIP--Dependency Inversion Principle）：高層模塊不應(yīng)該依賴于低層模塊,二者都應(yīng)該依賴于抽象。抽象不應(yīng)該依賴于細(xì)節(jié),細(xì)節(jié)應(yīng)該依賴于抽象。

四、什么是Command?

答題要點：將一個請求封裝為一個對象，從而使你可用不同的請求對客戶進行參數(shù)化；對請求排隊或者記錄請求日志以及支持可取消的操作。

五、說出你所知道的集中創(chuàng)建型模式。

答題要點：Factory Method，Abstract Factory，Builder，Prototype，Singleton