學習目標：

1、瞭解Java的歷史

2、為什麼要學習Java語言

3、端正學習態度

學習過程：

一、什麼是設計模式

源於《Design Patterns: Elements of Reusable Object-Oriented Software》即《設計模式》一書，由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 合著（Addison-Wesley，1995）。這幾位作者常被稱為"四人組（Gang of Four）"。在《設計模式》這本書的最大部分是一個目錄，該目錄列舉並描述了 23 種設計模式。

設計模式（Design pattern）是一套被反覆使用、經過分類編目的、總結了前輩們優秀的程式碼設計經驗一套模式。使用設計模式是為了可重用程式碼、讓程式碼更容易被他人理解、保證程式碼可靠性。

二、原則

為什麼要提倡設計模式呢？那些模式的設計才是好的模式呢？根本原則就是要實現程式碼複用，以提高程式碼的可維護性。那麼怎麼才能實現程式碼複用呢？在面向物件有幾個原則：

• 開閉原則（Open Closed Principle，OCP）

• 里氏代換原則（Liskov Substitution Principle，LSP）

• 依賴倒轉原則（Dependency Inversion Principle，DIP）

• 介面隔離原則（Interface Segregation Principle，ISP）

• 合成/聚合複用原則（Composite/Aggregate Reuse Principle，CARP）

• 最小知識原則（Principle of Least Knowledge，PLK，也叫迪米特法則）。

其中開閉原則具有理想主義的色彩，它是面向物件設計的終極目標。其他幾條，則可以看做是開閉原則的實現方法。優秀的設計模式就是實現了這些原則，從而達到了程式碼複用、增加可維護性的目的。

1、開閉原則

此原則是由Bertrand Meyer提出的。原文是：

“Software entities should be open for extension,but closed formodification”。

就是說模組應對擴充套件開放，而對修改關閉。模組應儘量在不修改原始碼的情況下進行擴充套件。

2、里氏代換原則

里氏代換原則是由Barbara Liskov提出的。如果呼叫的是父類的話，那麼換成子類也完全可以執行。

3、依賴倒轉原則

抽象不應該依賴於細節，細節應當依賴於抽象。要針對介面程式設計，而不是針對實現程式設計。傳遞引數，或者在組合聚合關係中，儘量引用層次高的類。主要是在構造物件時可以動態的建立各種具體物件，當然如果一些具體類比較穩定，就不必在弄一個抽象類做它的父類，這樣有畫蛇添足的感覺

4、介面隔離原則

定製服務的例子，每一個介面應該是一種角色，不多不少，不幹不該乾的事，該乾的事都要幹。

5、合成/聚合複用原則

合成/聚合複用原則（Composite/Aggregate Reuse Principle，CARP）經常又叫做合成複用原則。合成/聚合複用原則就是在一個新的物件裡面使用一些已有的物件，使之成為新物件的一部分；新的物件通過向這些物件的委派達到複用已有功能的目的。它的設計原則是：要儘量使用合成/聚合，儘量不要使用繼承。

6、最少知識原則

也叫迪米特法則。不要和陌生人說話。類的最小化。

三、23種模式簡介

四人組（Gang of Four）總共總結了23中優秀的設計模式，雖然後來還添加了幾種，不過一般設計模式還是以這23種劃分為主。下面簡單介紹一下：

1. 建立型模式：單例模式、抽象工廠模式、建造者模式、工廠模式、原型模式。

2. 結構型模式：介面卡模式、橋接模式、裝飾模式、組合模式、外觀模式、享元模式、代理模式。

3. 行為型模式：模版方法模式、命令模式、迭代器模式、觀察者模式、中介者模式、備忘錄模式、直譯器模式、狀態模式、策略模式、職責鏈模式、訪問者模式。

按字典序排列簡介如下：

Abstract Factory（抽象工廠模式）：提供一個建立一系列相關或相互依賴物件的介面，而無需指定它們具體的類。

Adapter（介面卡模式）：將一個類的介面轉換成客戶希望的另外一個介面。Adapter模式使得原本由於介面不相容而不能一起工作的那些類可以一起工作。

Bridge（橋接模式）：將抽象部分與它的實現部分分離，使它們都可以獨立地變化。

Builder（建造者模式）：將一個複雜物件的構建與它的表示分離，使得同樣的構建過程可以建立不同的表示。

Chain of Responsibility（職責鏈模式）：為解除請求的傳送者和接收者之間耦合，而使多個物件都有機會處理這個請求。將這些物件連成一條鏈，並沿著這條鏈傳遞該請求，直到有一個物件處理它。

Command（命令模式）：將一個請求封裝為一個物件，從而使你可用不同的請求對客戶進行引數化；對請求排隊或記錄請求日誌，以及支援可取消的操作。

Composite（組合模式）：將物件組合成樹形結構以表示“部分-整體”的層次結構。它使得客戶對單個物件和複合物件的使用具有一致性。

Decorator（裝飾模式）：動態地給一個物件新增一些額外的職責。就擴充套件功能而言， 它比生成子類方式更為靈活。

Facade（外觀模式）：為子系統中的一組介面提供一個一致的介面，Facade模式定義了一個高層介面，這個介面使得這一子系統更加容易使用。

Factory Method（工廠模式）：定義一個用於建立物件的介面，讓子類決定將哪一個類例項化。Factory Method使一個類的例項化延遲到其子類。

Flyweight（享元模式）：運用共享技術有效地支援大量細粒度的物件。

Interpreter（解析器模式）：給定一個語言, 定義它的文法的一種表示，並定義一個直譯器, 該直譯器使用該表示來解釋語言中的句子。

Iterator（迭代器模式）：提供一種方法順序訪問一個聚合物件中各個元素，而又不需暴露該物件的內部表示。

Mediator（中介模式）：用一箇中介物件來封裝一系列的物件互動。中介者使各物件不需要顯式地相互引用，從而使其耦合鬆散，而且可以獨立地改變它們之間的互動。

Memento（備忘錄模式）：在不破壞封裝性的前提下，捕獲一個物件的內部狀態，並在該物件之外儲存這個狀態。這樣以後就可將該物件恢復到儲存的狀態。

Observer（觀察者模式）：定義物件間的一種一對多的依賴關係,以便當一個物件的狀態發生改變時,所有依賴於它的物件都得到通知並自動重新整理。

Prototype（原型模式）：用原型例項指定建立物件的種類，並且通過拷貝這個原型來建立新的物件。

Proxy（代理模式）：為其他物件提供一個代理以控制對這個物件的訪問。

Singleton（單例模式）：保證一個類僅有一個例項，並提供一個訪問它的全域性訪問點。 單例模式是最簡單的設計模式之一，但是對於Java的開發者來說，它卻有很多缺陷。在九月的專欄中，David Geary探討了單例模式以及在面對多執行緒（multi-threading）、類裝載器（class loaders）和序列化（serialization）時如何處理這些缺陷。

State（狀態模式）：允許一個物件在其內部狀態改變時改變它的行為。物件看起來似乎修改了它所屬的類。

Strategy（策略模式）：定義一系列的演算法,把它們一個個封裝起來, 並且使它們可相互替換。本模式使得演算法的變化可獨立於使用它的客戶。

Template Method（模板方法模式）：定義一個操作中的演算法的骨架，而將一些步驟延遲到子類中。Template Method使得子類可以不改變一個演算法的結構即可重定義該演算法的某些特定步驟。

Visitor（訪問者模式）：表示一個作用於某物件結構中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用於這些元素的新操作。

有關設計模式的更詳細的介紹大家可以參考《Design Patterns: Elements of Reusable Object-Oriented Software》這本書，下面我們簡單的舉幾個模式介紹一下。