面向對象程序設計與原則

面向對象的程序
1.需求分析
2．總體設計
3．詳細設計階段
4．實現階段
一、需求分析階段：
以用例圖為主，到類分析圖為止。類圖是源碼的來源。用例的主功能用序列圖表示。用例的狀態可以用狀態圖標識， 注意活動圖要細化到與序列圖相同程度。
按照不同用戶畫出不同用例圖。按照不同物理位置畫出部署圖；按照不同類型用戶對程序進行分類，得到組件圖。從序列圖得到協作圖，並且進行簡單類分析，
得到類分析圖。序列圖的消息變成操作，消息中的信息變成屬性。
二、總體設計
為用戶所見的系統計算機層面，包括界面。
每一個用例的完整序列圖，包括主功能，備用功能，異常事件，錯誤輸入與錯誤處理等序列圖集，每一個分支一個序列圖。用一個活動圖歸並全部序列圖，
遇到分支用菱形框，得到用例的完整功能。細化用例圖，比較每一個用例的活動圖，得到相同的部分，分解成包含用例；對於復雜功能的用例，分解成多
個包含用例。對有些功能進行模塊化擴展，稱為擴展用例。對用戶與用例可以用繼承關系。
從序列圖得到協作圖，進行簡單類分析，特別是實體類。增加類：界面類，事務管理類。
畫出系統狀態圖（有活動表達式），對重要的類畫出類的狀態圖，從中得到新的屬性與操作。
對增加的類重新畫序列圖，活動圖與協作圖。分析類圖。
細化狀態圖。
狀態圖為主，應用類圖是重心，畫出全部用戶的細化用例圖，說明與其它系統的接口。
畫出系統總體設計圖，根據應用類圖與順序活動圖。建立UML總體模型。　　　
三、詳細設計階段
　　程序的內部結構與實現方案的詳細
類圖為主，重點是增加控制類。
從類圖得到程序的結構，從順序活動圖得到程序的過程（C++）．
重畫有控制類的序列圖、協作圖、活動圖。
.用協作圖將操作函數化，用返回值將屬性變量化
.給出類狀態圖的活動表達式。狀態圖的事件是序列圖的消息，是類的操作，活動表達式是轉換事件的實現，因此是類的操作的實現。
分解活動圖，根據某一個操作。與活動表達式不同。
將應用類圖變成設計類圖，用具體的語言，
子系統的划分：類圖，活動圖（模塊圖），組件圖，部署圖。
將類align到組件中，將組件到部署圖中。
建立程序設計的完整模型。
四、實現階段
建立並發視圖。
組件圖：可執行文件，配置文件。
部署圖：進程，設置硬件，例如打印機
軟件測試
產品階段

最基本的設計原則有5條，分別是：單一職責原則、開放封閉原則、依賴倒置原則、接口隔離原則和Liskov替換原則。
SRP，單一職責原則，一個類應該有且只有一個改變的理由。
OCP，開放封閉原則，你應該能夠不用修改原有類就能擴展一個類的行為。
LSP，Liskov替換原則，派生類要與其基類自相容。
DIP，依賴倒置原則，依賴於抽象而不是實現。
ISP，接口隔離原則，客戶只要關注它們所需的接口

REP，重用發布等價原則，重用的粒度就是發布的粒度。
CCP，共同封閉原則，包中的所有類對於同一類性質的變化應該是共同封閉的。
CRP，共同重用原則，一個包中的所有類應該是共同重用的。

ADP，無環依賴原則，在包的依賴關系圖中不允許存在環。
SDP，穩定依賴原則，朝着穩定的方向進行依賴。
SAP，穩定抽象原則，包的抽象程度應該和其穩定程度一致。


單一職責原則SRP，
　　對於單一職責原則，其核心思想為：一個類，最好只做一件事，只有一個引起它的變化。單一職責原則可以看做是低耦合、高內聚在面向對象原則上的引申，
將職責定義為引起變化的原因，以提高內聚性來減少引起變化的原因。職責過多，可能引起它變化的原因就越多，這將導致職責依賴，相互之間就產生影響，從
而大大損傷其內聚性和耦合度。通常意義下的單一職責，就是指只有一種單一功能，不要為類實現過多的功能點，以保證實體只有一個引起它變化的原因。專注，
是一個人優良的品質；同樣的，單一也是一個類的優良設計。交雜不清的職責將使得代碼看起來特別別扭牽一發而動全身，有失美感和必然導致丑陋的系統錯誤風險。

開放封閉原則
　　對於開放封閉原則，它是面向對象所有原則的核心，軟件設計說到底追求的目標就是封裝變化、降低耦合，而開放封閉原則就是這一目標的最直接體現。開
放封閉原則，其核心思想是：軟件實體應該是可擴展的，而不可修改的。也就是，對擴展開放，對修改封閉的。因此，開放封閉原則主要體現在兩個方面：
1、對擴展開放，意味着有新的需求或變化時，可以對現有代碼進行擴展，以適應新的情況。
2、對修改封閉，意味着類一旦設計完成，就可以獨立完成其工作，而不要對其進行任何嘗試的修改。實現開開放封閉原則的核心思想就是對抽象編程，而不對
具體編程，因為抽象相對穩定。讓類依賴於固定的抽象，所以修改就是封閉的；而通過面向對象的繼承和多態機制，又可以實現對抽象類的繼承，通過覆寫其方法
來改變固有行為，實現新的拓展方法，所以就是開放的。“需求總是變化”沒有不變的軟件，所以就需要用封閉開放原則來封閉變化滿足需求，同時還能保持軟件內
部的封裝體系穩定，不被需求的變化影響。

依賴倒置原則
　　對於依賴倒置原則，其核心思想是：依賴於抽象。具體而言就是高層模塊不依賴於底層模塊，二者都同依賴於抽象；抽象不依賴於具體，具體依賴於抽象。我們
知道，依賴一定會存在於類與類、模塊與模塊之間。當兩個模塊之間存在緊密的耦合關系時，最好的方法就是分離接口和實現：在依賴之間定義一個抽象的接口使得
高層模塊調用接口，而底層模塊實現接口的定義，以此來有效控制耦合關系，達到依賴於抽象的設計目標。抽象的穩定性決定了系統的穩定性，因為抽象是不變的，
依賴於抽象是面向對象設計的精髓，也是依賴倒置原則的核心。
依賴於抽象是一個通用的原則，而某些時候依賴於細節則是在所難免的，必須權衡在抽象和具體之間的取舍，方法不是一層不變的。依賴於抽象，就是對接口編
程，不要對實現編程。

接口隔離原則
　　對於接口隔離原則，其核心思想是：使用多個小的專門的接口，而不要使用一個大的總接口。具體而言，接口隔離原則體現在：接口應該是內聚的，應該避免
“胖”接口。一個類對另外一個類的依賴應該建立在最小的接口上，不要強迫依賴不用的方法，這是一種接口污染。接口有效地將細節和抽象隔離，體現了對抽象編
程的一切好處，接口隔離強調接口的單一性。而胖接口存在明顯的弊端，會導致實現的類型必須完全實現接口的所有方法、屬性等；而某些時候，實現類型並非需
要所有的接口定義，在設計上這是“浪費”，而且在實施上這會帶來潛在的問題，對胖接口的修改將導致一連串的客戶端程序需要修改，有時候這是一種災難。在這
種情況下，將胖接口分解為多個特點的定制化方法，使得客戶端僅僅依賴於它們的實際調用的方法，從而解除了客戶端不會依賴於它們不用的方法。分離的手段主
要有以下兩種：
1、委托分離，通過增加一個新的類型來委托客戶的請求，隔離客戶和接口的直接依賴，但是會增加系統的開銷。
2、多重繼承分離，通過接口多繼承來實現客戶的需求，這種方式是較好的。

Liskov替換原則
　　對於Liskov替換原則，其核心思想是：子類必須能夠替換其基類。這一思想體現為對繼承機制的約束規范，只有子類能夠替換基類時，才能保證系統在運行期
內識別子類，這是保證繼承復用的基礎。在父類和子類的具體行為中，必須嚴格把握繼承層次中的關系和特征，將基類替換為子類，程序的行為不會發生任何變化。
同時，這一約束反過來則是不成立的，子類可以替換基類，但是基類不一定能替換子類。Liskov替換原則，主要着眼於對抽象和多態建立在繼承的基礎上，因此只
有遵循了Liskov替換原則，才能保證繼承復用是可靠地。實現的方法是面向接口編程：將公共部分抽象為基類接口或抽象類，通過Extract Abstract Class，在子
類中通過覆寫父類的方法實現新的方式支持同樣的職責。Liskov替換原則是關於繼承機制的設計原則，違反了Liskov替換原則就必然導致違反開放封閉原則。
Liskov替換原則能夠保證系統具有良好的拓展性，同時實現基於多態的抽象機制，能夠減少代碼冗余，避免運行期的類型判別。

1) Open-Close Principle（OCP），開-閉原則，講的是設計要對擴展有好的支持，而對修改要嚴格限制。這是最重要也是最為抽象的原則，基本上我們所說的
Reusable Software既是基於此原則而開發的。其他的原則也是對它的實現提供了路徑。
2) Liskov Substituition Principle（LSP），里氏代換原則，很嚴格的原則，規則是“子類必須能夠替換基類，否則不應當設計為其子類。”也就是說，子類只
能去擴展基類，而不是隱藏或覆蓋基類，如有這方面需要的設計就應當參考以下兩種方法替換：
3) Dependence Inversion Principle（DIP），依賴倒換原則，“設計要依賴於抽象而不是具體化”。換句話說就是設計的時候我們要用抽象來思考，而不是一上
來就開始划分我需要哪些哪些類，因為這些是具體。這樣做有什么好處呢？人的思維本身實際上就是很抽象的，我們分析問題的時候不是一下子就考慮到細節，而
是很抽象的將整個問題都構思出來，所以面向抽象設計是符合人的思維的。另外這個原則會很好的支持OCP，面向抽象的設計使我們能夠不必太多依賴於實現，這樣
擴展就成為了可能，這個原則也是另一篇文章《Design by Contract》的基石。
4) Interface Segregation Principle（ISP），“將大的接口打散成多個小接口”，這樣做的好處很明顯，我不知道有沒有必要再繼續描述了，為了節省篇幅，
實際上我對這些原則只是做了一個小總結，如果有需要更深入了解的話推薦看《Java與模式》，MS MVP的一本巨作！^_^
5) Composition/Aggregation Reuse Principle（CARP），設計者首先應當考慮復合/聚合，而不是繼承（因為它很直觀，第一印象就是“哦，這個就是OO啊”）。
這個就是所謂的“Favor Composition over Inheritance”，在實踐中復合/聚合會帶來比繼承更大的利益，所以要優先考慮。
6) Law of Demeter or Least Knowlegde Principle（LoD or LKP），迪米特法則或最少知識原則，這個原則首次在Demeter系統中得到正式運用，所以定義為
迪米特法則。它講的是“一個對象應當盡可能少的去了解其他對象”。也就是又一個關於如何松耦合（Loosely-Coupled）的法則。