今天聽了《C#面向對象設計模式縱橫談(1)：面向對象設計模式與原則》課程。總結了一些筆記。
?首先介紹了什么是設計模式：設計模式描述了軟件設計過程中某一類常見問題的一般性的解決方案。
?下面主要討論面向對象設計模式。
?面向對象設計模式描述了類與相互通信的對象之間的組織關系。目的是應對變化、提高復用、減少改變。
?那到底什么是對象：
??1、從概念層面講，對象是某種擁有職責的抽象；
??2、從規格層面講，對象是一系列可以被其他對象使用的公共接口；
??3、從語言實現層面來看，對象封裝了代碼和數據（也就是行為和狀態）。
?
對于這三點，我理解最深的應該是第三點。這可能和我把大多精力放在了代碼實現上有關，然而忽略了編程的的思想。如果我們拋開代碼的實現來看對象的概念，那
么它應該就像一個具體的物體，比如說：榔頭，從概念層面講，榔頭有它的職責，也就是它是做什么用的（用來砸釘子，當然還會有其他用途，如防身），從規格層
面講，比如人使用榔頭砸釘子。
?面向對象的設計模式有三大原則：
??1、這對接口編程，而不是針對實現編程。在知道設計模式之前，我對接
口的出現很不理解。不明白為什么這個什么都不能實現的東西會存在，當然，也對多態表示茫然。實際上我是還沒有理解面向對象編程的思想。在對設計模式略有了
解后發現接口的確是一個好東西，用它實現多態的確減少了代碼的修改。
?比如說在《Head First Design
Patterns》中有一個例子，說一個有關鴨子的游戲。游戲當中有很多種的鴨子，如：野鴨，木頭鴨，鴨子模型。我們首先會想到做一個抽象類：
abstract class Duck，Duck當中有很多的抽象屬性和方法，如quack。我們用子類繼承的時候都會實例化這個方法。
?public abstract class Duck
?{
??public abstract void quack()
?}
?
?public class MallardDuck:Duck
?{
??public override void quack()
??{
???Console.Write("I can quack");
??}
?}
當
程序成型后，我們有了很多種鴨子，突然，我們發現有的鴨子會飛，我們會在Duck中在加上一個抽象方法abstract void
fly();于是我們不得不在所有的子類當中添加fly的實現，有人會說，如果我們在Duck中直接添加fly的實現，不久不用在子類中添加實現了嗎？那
老板就該問你：你見過木頭鴨子滿天飛（哦，天啊！木頭鴨子也飛起來了，這是什么世界！）。對不起老板，現在咱們都見到了。
?這時我們換一種想法，如果我們把這些方法都提取出來,把它變成Duck的成員，好像問題就會簡單些。
?哈哈，好像扯的有點遠了，現在回來接著記我的筆記。
??2、優先使用對象組合，而不是類的繼承。
?這就使說多使用“has a”，少使用“is a”，哈哈，我又想說回剛才的例子。換個角度考慮Duck及其功能，我們設計一個fly的接口和一些具體的飛行方法。
?public interface FlyBehavior
?{
??void fly();
?}
?public class FlyWithWing:FlyBehavior
?{
??public void fly()
??{
???Console.Write("I can fly\n");
??}
?}
?public class FlyNoWay:FlyBehavior
?{
??public void fly()
??{
???Console.Write("I can't fly\n");
??}
?}?
?好了，對于Duck來說，現在它應該有一個（has a）fly的方法
?public abstract class Duck
?{
??public Duck()
??{}
??public FlyBehavior flybehavior;?
?}
?現在我們再來實現兩種鴨子
?public class ModelDuck:Duck
?{
??public ModelDuck()
??{
???flybehavior = new FlyNoWay();
??}
?}
?
?public class MallardDuck:Duck
?{
??public MallardDuck()
??{
???flybehavior = new FlyWithWing();
??}
?}
?這樣如果要是在加上某種行為的話，我們就不必在每一種鴨子上下功夫。把注意力放在我們關心的鴨子品種上（別太使勁關注，小心禽流感，“阿切！”）。
??3、封裝變化點，實現松耦合，這點不用多說了。
?課程中提到，編碼當中的設計模式使用不是我們在編程之初就定下來的，應該是重構得到設計模式（Refactoring to Patterns）。哦，原來是這樣，也好理解。在編碼中遇到問題，然后想想應對方式。哈哈，我原來認為開始編程時就指定我們用什么設計模式呢。
?下面說說設計原則：
??1、單一職責原則（SRP）：一個類應僅有一個引起它變化的原因。
??2、
開放封閉原則（OCP）：類模塊應可擴展，不可修改。這里要說明一下，擴展和修改是不同的。比如：我們要在加一種ModelDuck，那么我們寫一個
ModelDuck的類繼承Duck，這叫擴展，不是修改。什么是修改，就好像我們開始說的那種作法，為了加一個fly的功能，我們要把所有的子類中加入
不同的實現，這叫修改。
??3、Liskov替換原則：子類可替換基類。
??4、依賴倒置原則：高層模塊不依賴于低層模塊，二者都依賴于抽象。還是剛才的例子：Duck是一個高層模塊，fly是低層模塊。Duck不依賴于fly，高層模塊的改變慢，而低層模塊的改變慢。
???? 抽象不應依賴于實現細節，實現細節應依賴于抽象。fly是一個抽象，它不依賴如何飛行。
??5、接口隔離原則：不強迫客戶程序依賴于它們不用的方法（有道理，木頭鴨子不會飛為什么要讓它實現飛的功能。）
??最后有人提問接口和抽象類的區別：
???接口可以多繼承，抽象類只能但繼承。接口定義組件間的合同。使用抽象類為一個is a的關系。