程式設計語言的設計模式

面向對象設計原則

單一職責原則:

類的職責要單一，不能将太多的職責放在一個類中。

開閉原則:

軟體實體對擴充是開放的，但對修改是關閉的，即在不修改一個軟體實體的基礎去擴充其功能。

裡氏代換原則:

在軟體系統中，一個可以接受基類對象的地方必然可以接受一個子類對象。

依賴倒轉原則:

要針對抽象層編輯，而不要針對具體類程式設計。

接口隔離原則:

使用多個專門的接口來取代一個專門的接口。

合成複用原則:

在系統中應該盡量多使用組合和聚合關聯關系，盡量少使用甚至不使用繼承關系。

迪米特法則:

一個軟體實體對其他實體的引用越少越好，或者說如果兩個類不必彼此直接通信，那麼這兩個類就不應當發生直接的互相作用，而是通過引入一個第三者發生間接互動。

單例模式

確定一個類僅有一個唯一的執行個體，并且提供一個全局的通路點。

思路：

首先将構造函數聲明成私有類型，屏蔽通過直接執行個體化的形式來通路。

其次控制全局隻有一個執行個體的類--Static

第三，提供一個可以獲得執行個體的方法，用于傳回類的執行個體，并保證得到的是同一個對象。

示例:

第一種：

class Singleton

{

    private static Singleton singleton;

    private Singleton(){

    }

    public static Singleton getInstance()

    {

        if(singleton==null)

        {

            singleton = new Singleton();

        }

        return singleton;

}

第二種:

    private static Singleton singleton=new Singleton();

    public static Singleton getInstance(){

    } 

政策模式

政策模式定義了一系列的算法，并将每一個算法封裝起來，而且使它們還可以互相替換。政策模式讓算法獨立于使用它的客戶而獨立變化。

擴充卡模式中的有以下三種角色:

抽象政策類(Strategy):定義是以支援的算法公共接口。

具體政策類(ConcreteStrategy):以Strategy接口實作某具體算法。

環境類(Context):維護一個對Strategy對象的引用。可定義一個接口來讓Strategy通路它的資料。

政策模式實作步驟:

定義抽象政策類

實作具體政策類

定義環境類

觀察者模式

兩個角色:觀察者和被觀察者

當被觀察者發生改變的時候，觀察者就會觀察到這樣的變化，并且做出相應的響應。

實作觀察者模式有很多形式，比較直覺的一種“注冊-通知-撤銷注冊”的形式。

觀察者模式實作步驟:

觀察者将自己注冊到被觀察對象中，被觀察對象将觀察者存放在一個容器裡。

被觀察對象發生了某種變化，從容器中得到所有注冊過的觀察者，将變化通知觀察者。

觀察者告訴被觀察者要撤銷觀察，被觀察者從容器中将觀察者去除。

擴充卡模式

擴充卡模式有以下四種角色:

目标(target):定義用戶端使用的與特定領域相關聯的接口。

被适配者(adaptee):定義了一個已經存在的接口，這個接口需要比對。

适配者(adapter):對Adaptee的接口與target的接口進行适配。

用戶端(Client):與符合target接口的對象協同。

類擴充卡:

确定目标接口

确定被适配者

建立擴充卡

對象擴充卡:

組合模式

又叫做“整體-部分模式”

它使樹型結構的問題中，模糊了簡單元素和複雜元素的概念，客戶程式可以向處理簡單元素一樣來處理複雜元素，進而使得客戶程式與複雜元素的内部結構解耦。

組合模式有以下三種角色:

抽象元件類(Component):組合中的對象聲明接口，實作所有類共有接口的行為。聲明用于通路和管理Component的子部件的接口。

葉子節點(Leaf):葉節點對象，葉節點沒有子節點。由于葉子節點不能增加分支和樹葉，是以葉節點的Add和Remove沒有實際意義。有葉節點行為，用來存儲節點集合。

元件集合類(Composite):實作Component的相關操作，比如Add和Remove操作。其中包含Component的容器，用來存儲葉節點的集合。

組合模式實作步驟:

定義抽象元件接口

實作葉子節點類，實作抽象元件類的接口

實作元件集合類，實作抽象元件類的接口

定義環境類，講葉子節點群組件集合加入跟元件集合

裝飾模式:

模式中的角色:

裝飾者(decorator)是用來裝飾的

被裝飾者(decoratee)是被裝飾的對象

Decorator模式解決的問題:

動态給一個對象添加一些額外的功能和職責。

指令模式

将一個請求封裝為對象，進而使你可用不同的請求對客戶進行參數化；

指令模式可以對發送者和接收者完全解耦，發生者與接收者之間沒有直接引用關系，發送請求的對象隻需要知道如何發送請求，而不必知道如何完成請求。

指令模式的角色

Command:定義指令的接口

ConcreteCommand:指令接口實作對象，通常會持有接收者，并調用接收者的功能來完成指令要執行的操作。

Receiver:接收者，真正執行指令的對象。

Invoker:傳遞者，要求指令對象執行請求，通常會持有指令對象，可以持有很多的指令對象。

Client:建立具體的指令對象，并且設定指令對象的接收者。組裝指令對象和接收者，因為真正使用指令的用戶端是從Invoker來出發執行的。

狀态模式

狀态模式解決的問題:

允許一個對象在其内部狀态改變的時候改變它的行為。

角色:

環境類(Context):客戶使用的對象類。維護一個State子類的執行個體，這個執行個體定義目前狀态。

抽象狀态類(State):定義一個抽象以封裝與Context的一個特定狀态相關的行為。

具體狀态類(ConcreteState):每一子類實作一個與Context的一個狀态相關的行為。

狀态模式實作步驟如下:

定義抽象狀态類，實作目前系統的真實狀态繼承此自此抽象狀态類。

定義Context類，具體狀态的類，其中包含抽象狀态類的對象。

定義具體狀态類，實作目前系統的真實狀态類。

當Context類執行某個抽象的方法時，去調用真實狀态類的實作方法。

當Context類修改狀态時，修改Context類的真實狀态對象。

橋接模式

按緯度分成獨立部分來對待

然後使用對象組合方式把它們連接配接起來

疊代器模式

又叫做遊标模式

提供一種方法通路一個容器(container)對象中各個元素，而又不暴露該對象的内部細節。

疊代器模式是為容器而生。

疊代器模式包括四種角色:

抽象集合:

一個接口，規定了具體集合需要實作的操作。

具體集合:

具體的集合按照一定的結構存儲對象。

具體集合應該有一個方法，該方法傳回一個針對該集合的具體疊代器。

抽象疊代器:

一個接口，規定了周遊具體集合的方法，比如next()方法。

具體疊代器:

實作了疊代器接口的類的執行個體。