極限編程中的簡單設計原則

1.考慮能夠工作的最簡單的事情
        XP團隊最開始的工作是以儘可能簡單的方式實現第一批使用者需求。儘可能尋找實現目前使用者需求的最簡單的設計。在實現當前的使用者需求時，如果能夠使用一般檔案，就不去使用資料庫或者EJB；如果能夠使用簡單的socket串連，就不去使用ORB或者RMI；如果能夠不使用多線程就別去用它。
       
        2.假設將不需要某些基礎結構
        XP團隊的工作可能不會從基礎結構開始，他們可能並不先去選擇使用資料庫或中介軟體。開始時假設將不需要那些基礎結構。只有在有證據，或者至少有十分明顯的跡象表明現在引入這些基礎結構比繼續等待更加合算是，才將其引入。
       
        3.消除重複的代碼
        無論在哪裡發現重複的代碼，都應該消除它們。當發現那些重複的代碼時，可以通過定義一個函數或基類的方法消除它們。有時兩個或多個演算法非常相似，但是它們之間存在著微妙的差別，就將它們變成函數，或者使用TEMPLATE METHOD模式。
        消除重複的最好方法就是抽象。畢竟，如果兩種事物相似的話，必定存在某種抽象能夠統一它們。消除重複的行為會迫使團隊提煉出許多抽象，並進一步減少了代碼間的耦合。

        簡單的設計最重要的特性就是容易適應變化.為了達到這樣的目的,簡單設計應當:
       
        能夠簡單地被理解.這依賴於你代碼的可理解性.只有可理解,下面的簡單性才能達到.
        能夠簡單地被修改和擴充.OO系統往往通過增量的方法改變或增加系統行為,所以也就是要被簡單地重用,這要求我們沒有重複代碼.
        有最少數目的類.要易於理解系統,那麼系統中每一個類應當和需要解決的問題的每一個重要概念相對應,如果人工加入許多毫無意義的類或者太多與問題概念無法對應的類,系統將無法理解
        有最少數目的方法.每一個方法應該有他獨立的意義, 如果沒有可以言述意圖的名字,那麼系統將難以理解.