摘要：設計模式設計模式基本原則設計原則按接口而不是按實現來編程按接口而不是按實現編程是指，要將變量設置為一個抽象類或接口數據類型的實例，而不是一個具體實現的實例。例如父類的一個改變會逐級向下傳遞給子類實現，這可能會影響子類使用的某個算法。

設計原則 ① : 按接口而不是按實現來編程

按接口而不是按實現編程是指，要將變量設置為一個抽象類或接口數據類型的實例，
而不是一個具體實現的實例。這樣可以將設計與實現解耦合。
有些語言變量聲明包含數據類型，例如在一個強類型語言中可以有以下聲明：

如果沒有強類型機制，可以利用代碼提示保證按接口編程，以上一節寫過的一段代碼為例

doInterface($apple);
        $this->doInterface($book);
    }
    function doInterface(IProduct $product){
    //這里的IProduct $product就是一種類型提示，方法類型提示為接口IProduct
    //無論程序變得多復雜都沒關系,只要保證接口
    //就可以做出任意的修改和增補，不會破壞程序的其它部分
        echo $product->apples();
        echo $product->books();
    }
}
$worker = new useProduct();
?>

設計原則 ② : 應當優先選擇對象組合而不是類繼承

有的OOP程序猿認為對象重用就等同于繼承，一個類可以有大量屬性和方法，擴展這個類就可以重用所有那些對象元素，而不用重新編寫代碼。可以擴展類，再增加必要的新屬性和方法。下面將舉一個例子說明對象組合和類繼承之間的區別。

首先是繼承的代碼

sum = ( $first + $second );
        return $this->sum;
    }
    public function simpleDivide($divided, $divisor){
        $this->quotient = ( $dividend / $divisor);
        return $this->quotient;
    }
}
?>

textOut = (string)$num;
        return $this->textOut;
    }
    public function addFace($face,$msg){
        $this->fullFace = "" . $face . " : " .$msg;
        return $this->fullFace;
    }
}
?>

added = $family->simpleAdd(40,60);
        $this->divided = $family->simpleDivided($this->added,25);
        $this->textNum = $family->numToText($this->divided);
        $this->output = $family->addFace("Your results",$this->textNum);
        echo $this->output;
    }
}
$worker = new ClientInherit();
?>

下面是組合，Client類使用兩個不同的類，分別包含兩個方法，DoMath類等同于繼承例子中的父類，所以首先是DoText類

textOut = (string)$num;
        return $this->textOut;
    }
    public function addFace($face,$msg){
         $this->fullFace = "" . $face . " : " .$msg;
        return $this->fullFace;
    }
}
?>

added = $useMath->simpleAdd(40,60);
        $this->divided = $useMath->simpleDivide($this->added,25);
        $this->textNum = $useText->numToText($this->divided);
        $this->output = $useText->addFace("Your results",$this->textNum);
        echo $this->output;
    }
}
?>

Client類必須包含多個類，看起來更勝一籌，不過在較大的程序中，組合可以避免維護多個繼承層次上的各個子類，而且還可以避免可能導致的錯誤。例如父類的一個改變會逐級向下傳遞給子類實現，這可能會影響子類使用的某個算法。
要避免使用繼承形成一長串子類、孫子類、曾孫子類，設計模式方法建議使用淺繼承。

設計模式是按照作用和范圍來組織的

設計模式按作用可以分為以下3類

創建型

顧名思義，就是用來創建對象的模式，更確切地講，這些模式是對實例化過程的抽象，
如果程序越來越以來組合，就會減少對硬編碼實例化的依賴，而更多地以來于一組靈
活的行為，這些行為可以組織到一個更為復雜的集合中，創建型模式提供了一些方法
來封裝系統使用的具體類的有關知識，還可以隱藏實例創建和組合的相關信息

結構型

這些模式所關心的是組合結構應當保證結構化。結構型類模式采用繼承來組合接口或實現。結構型對象模式則描述了組合對象來建立新功能的方法。了解結構型模式對于理解和使用相互關聯的類（作為設計模式中的參與者）很有幫助

行為型

到目前為止，絕大多數模式都是行為型對象，這些模式的核心是算法和對象之間職責的分配。這些設計模式描述的不只是對象或類的模式，它們還描述了類和對象之間的通信模式

設計模式按范圍可以分為以下2類

類
在兩類范圍中，第一類范圍是類。這些類模式的重點在于類及其子類之間的關系，類模式中的關系是通過繼承建成

對象
盡管大多數設計模式都屬于對象范圍，不過與類范圍中的那些模式一樣，很多模式也會使用繼承。對象設計模式與類模式的區別在于，對象模式強調的是可以在運行時改變的對象，因此這些模式更具動態性。

設計模式作用、范圍和變化

與框架相比，設計模式是體系結構中更小的元素，也更為抽象，另外設計模式沒有框架那么
特定。因此，設計模式更可重用，也比框架靈活。
框架的有點與模板有些類似：它們更有指示性，可以更清楚地指示所解決問題的結構。為了
提供這種易用性，它們不得不放棄了體系結構的靈活性。如果使用框架，構建應用會快得多，
但是所構建的應用會受到框架本身的約束。框架可以包含面向對象結構，通常框架是分層的，
每一層處理更大設計中的一個方面。框架的一些特性在設計模式中也有體現，不過，設計模
式沒有框架那么特定和具體，也沒有那么龐大

概念：UML(the Unified Modeling Language——統一建模語言),引入了一個強大的
圖形化的語法來描述面向對象系統

類是類圖的主要部分，類用帶有類名的方框來描述。

上圖中，圖1最先顯示的是類的名稱，下面兩部分是可選的，用于顯示類名之外的信息。
可以發現圖1已經足夠描述一些類，并非總要在類圖中顯示每個屬性和方法，甚至不需要
顯示每個類

通常用斜體的類名（圖2），或者增加{abstract}到類名下(圖3)來表示該類是抽象
類。 第一種方法比第一種方法常用，但是當你做筆記時第二種方法更有用

接口定義的方式和類相同，但接口必須使用一個衍型(UML的一個擴展)，如樓下所示

一般來說，屬性用于描述一個類的屬性，屬性直接列在類名下面的格子中，如樓下所示

屬性前面的符號表示該屬性可見性的級別或者是訪問控制

冒號用于分隔屬性名和它的類型及默認值(默認值為可選項，可以不提供)
Again:只要提供必要的信息，不需要所有細節

操作用于描述類方法，操作和屬性使用了相似的語法

（1）可見性符號放在方法名之前
（2）參數列表包含在括號之中
（3）方法如果有返回類型的話，用冒號來描述
（4）參數用逗號來分隔，并且遵守屬性語法
（5）參數名和它的數據類型間用冒號分隔

如下圖所示

繼承關系用從子類到父類的一條線來表示，線的頂端有一個空心閉合箭頭

UML用"實現"來描述接口和實現接口的類之間的關系，如果ShopProduct類實現了Chargeable接口，就可以加入類圖中，如圖所示

一個類的屬性保存了對另一個類的一個實例或多個實例的引用時，就產生了關聯
下圖中為輛各類建立模型，并創建類之間的關聯，圖中指出Teacher對象擁有一個或多個對Pupil對象的引用，或者Pupil對象擁有一個或多個對Teacher對象的引用

我們可以用剪頭來描述關聯的方向，如果Teacher類擁有Pupil類的一個實例，但是Pupil類并沒有Teacher類的實例，那我們可以讓關聯剪頭從Teacher類指向Pupil類，稱為"單向關聯"

如果兩個類剪互相擁有對方的引用，可以用一個雙向剪頭來描述這種"雙向關聯"關系

也可以在關聯中指定一個類的實例被其它類引用的次數，可以通過把次數或者范圍放在每個類旁邊來說明。用星號(*)表示任意次數，如下圖所示，Teacher對象擁有零個或多個Pupil對象

都描述了一個類長期持有其它類的一個或多個實例的情況，通過聚合和組合，被
引用的對象實例成為引用對象的一部分。
聚合關系用一條以空心菱形開頭的線來說明,如下圖所示，定義了兩個類，
SchoolClass和Pupil， SchoolClass類聚合了Pupil
（意思就是學生組成了班級，如果我們要刪除一個學校類，不需要同時刪除）

組合是一個更強的關系，在組合中，被包含對象只能被它的容器所引用，當容器刪除
時，她應該也被刪除，組合關系用類似聚合關系的方式描述，但它的菱形是實心的
下圖中,Person類持有對SocialSecurityData對象的引用，而SocialSecurityData
對象實例屬于包含它的Person對象

使用：即依賴關系，并非類之間的長久關系
下圖中，Report類使用了ShopProductWriter對象，這種使用關系由一條連接兩個類
的虛線和開放剪頭表示。Report類沒有把ShopProductWriter保存為類中的屬性，
ShopProductWriter對象則將一組ShopProduct對象作為屬性

注解：解釋類處理任務的過程（類圖只能捕捉系統結構）
如下圖，Report對象使用了ShopProductWriter，但是不知道具體如何實現，
我們使用了注解來補充說明

如圖所示，注解由一個這叫的方框組成，通常包含偽代碼片段

時序圖是基于對象而不是基于類的，用于為系統中過程化的行為建模。

如下，為Report對象輸出產品數據的過程建模，從左到右展現了系統的參與者
我們值使用類名來標記對象，如果圖中有同一個類的多個對象實例在獨立工作，
可以使用label:class(例如product1 : ShopProduct)格式來包含對象名

下圖我們從上到下展示了該過程每個對象的生命周期

垂直的虛線是生命線，展示了系統中對象的生命周期，生命線上的矩形說明了過程中的
焦點，即某個對象的激活期。
顯示對象間傳遞的消息，這個圖才更容易被看懂，如下

箭頭表示消息從一個對象傳遞到另一個對象，返回值一般不寫。
每個消息都用相關的方法調用來標記，例如方括號說明一個條件，像
{okToPrint}
write()
只有在一定條件下write才會被執行
星號用于表示一個重復的操作，可以在方括號中進一步說明
*{for each ShopProduct}
write()

該圖含義：Report對象獲得一個來自ProductStore對象的ShopProduct對象列表。
Report對象傳遞這個ShopProduct列表給一個ShopProcuctWriter對象，而
ShopProductWriter存放了對ShopProduct對象的引用(雖然我們只能從圖中推斷
出折點)ShopProductWriter對象為它引用的每個ShopProduct對象調用ShopProduct::
getSummaryLine(),并添加執行結果到最終的輸出結果中

本文筆記參考書籍：
《深入PHP：面向對象、模式與實踐》第4章
《Learning-PHP設計模式》第4章

下節：Chap3：創建型設計模式————工廠方法設計模式