初探面向物件程式設計之oop與設計模式
1. 程式設計方式
我們目前的程式設計方式大體可以有以下三種程式設計方式：
- 順序程式設計
- 程序式程式設計
- 面向物件程式設計
在講面向物件程式設計時先講一下什麼是順序程式設計，什麼是程序式程式設計，什麼是面向物件程式設計：
- 順序程式設計： 就是隻用一個單執行緒去執行一段程式碼，執行過程根據程式碼依次從上到下按順序執行各種指令操作
- 程序式程式設計：過程式的程式設計中心是圍繞著程式碼，比如當程式執行到某一個位置的時候回撥用一個其他的方法來實現剩餘的業務邏輯，然後程式繼續往下執行，這就是程序式程式設計。通俗一點使用函式的方式來編寫程式碼都屬於程序式程式設計，更深層次的，例如某些PHP開發者雖然使用了類的概念來寫程式，但是還是區域過程式的方式程式設計，doris周圍的大多數同事就是如此，包括doris在瞭解面向物件程式設計之前也同樣採用過程式的方式寫程式。
- 面向物件程式設計：通俗的講就是就是在寫程式時，我們程式設計師自己設計出N多個物件（工作者）出來分工合作一起完成某項任務，這就是面向物件程式設計。這裡說設計多個物件，那麼我們如何去設計？這就是doris接下來的一段時間裡與大家一起分享doris對面向物件的一些看法及平時工作中的一些總結了。
2. 為什麼要採用面向物件程式設計
2.1 解決問題更容易
設計計算機程式就是為了解決人類的問題。其策略就是講大的問題拆分成小的問題來逐一解決，而面向物件大體的講就是這個原理，將大的複雜的問題進行拆分由小的個體來完成然後再進行組裝就可以把這個複雜的問題逐一破解，這就是模組化設計風格。你可能認為模組化看起來並不太難。沒錯，問題越複雜，模組化就越有意義。所以OOP程式設計的出發點絕對不是要把複雜的問題更復雜化，反而是是要把複雜的問題簡單化。即使是最困難的程式設計問題也可以採用這種分而治之
2.2 開發和修改速度更快
在團隊合作中特別能體現面向物件程式設計的優越性，我們可以大的問題拆分成很多個小的問題，模組的目的就是解決比較複雜的問題的某一方面，這樣我們就得到了面向物件程式設計的首要原則之一（即單一職責原則），並將這些小問題進行組裝（意思就是程式碼架構）起來，然後在把這些小的問題分配給其它開發人員，進行開發，這樣在開效率上可以大大提高開發效率，並且開發者之間的程式碼衝突也會降到最低。
類似於OPP，程序式程式設計也是用了模組和重用。不過，程序式程式設計沒有提供類（利用類，貶稱任務可以打包到物件）。類物件（類例項）可以處理自己的資料結構，這是函式無法單獨做到的，因此，如果採用程序式程式設計，完成大型任務往往需要很長時間的序列。另外，採用程序式程式設計時，團隊合作也比較困難，因為不同的團隊成員無法像採用OPP那樣輕鬆地處理獨立單相互關聯的類。
3. 為什麼面向物件如此之難
如果問doris為什麼面向物件那麼難就好比問doris為什麼架構師工資那麼高且沒幾個人達得到是同一個問題。因為面向物件程式設計是需要程式設計經驗的一個提煉的，如果經驗越豐富那麼面向物件程式的設計就越靈活，這裡說的經驗是指使用面向物件程式設計的經驗，而不是上文提到的順序程式設計和程序式程式設計那些經驗。面向物件程式設計需要對業務及程式碼的架構是有一定的要求的。一切程式的設計都離不開業務邏輯。在學習OOP和設計模式時，你需要記住：
- 設計面向物件軟體很困難
- 設計可重用面向物件軟體更困難
當然啦，不能把這些說法作為放棄學習OOP和設計模式的理由，而應當由此看出OPP和設計模式為什麼這麼有意義。知識會增加技能的價值，得到知識越困難，說明它就越有價值。
4. 如何學習OOP思想及設計模式
不要期望能輕鬆快速地掌握OOP和設計模式，要在你的程式設計中逐步滲入，一次結合一點，總有一天你會發現它的價值所在。過一段時間後，你會擁有更多的技能，有更深入的理解。你可能會遇到某個專案，發現可以在其中重用之前另外一個專案的大部分程式結構。
5. 面向物件程式設計基本原則
我們在使用面向物件程式設計時一定要記住以下幾個基本原則（也就是設計面向物件程式的基本原則），這樣才能夠更好的理解面向物件的深意。
5.1 單一職責原則
本著低耦合、高內聚原則，一個類做一件事。
對於單一職責原則，其核心思想為：一個類，最好只做一件事，只有一個引起它的變化。單一職責原則可以看做是低耦合、高內聚在面向物件原則上的引申，將職責定義為引起變化的原因，以提高內聚性來減少引起變化的原因。職責過多，可能引起它變化的原因就越多，這將導致職責依賴，相互之間就產生影響，從而大大損傷其內聚性和耦合度。通常意義下的單一職責，就是指只有一種單一功能，不要為類實現過多的功能點，以保證實體只有一個引起它變化的原因。
5.2 開放封閉原則
當我們軟體的實際應用發生改變時，出現新的需求，就需要我們對模組進行擴充套件，使其能夠滿足新的需求！更改封閉即是在我們對模組進行擴充套件時，勿需對源有程式程式碼和DLL進行修改或重新編譯檔案！這個原則對我們在設計類的時候很有幫助，堅持這個原則就必須儘量考慮介面封裝，抽象機制和多型技術！通俗的講就是：對擴充套件開放、對修改關閉
5.3 里氏替換原則（LSP）
意思就是說我們依賴父類介面，在客戶端宣告一個父類介面，通過其子類來實現，這個時候就要求子類必須能夠替換父類所出現的任何地方，這樣做的好處就是，在根據新要求擴充套件父類介面的新子類的時候而不影響當前客戶端的使用！
5.4 依賴倒置原則
傳統的結構化程式設計中，最上層的模組通常都要依賴下面的子模組來實現，也
稱為高層依賴低層！所以DIP原則就是要逆轉這種依賴關係，讓高層模組不要依賴低層模組，所以稱之為依賴倒置原則！通俗一點就是（面向介面程式設計）
5.5 ISP 介面隔離原則
這個原則的意思是：使用多個專門的介面比使用單個介面要好的多！為了減少介面的定義，將許多類似的方法都放在一個介面中，最後發現，維護和實現介面的時候花了太多精力，而介面所定義的操作相當於對客戶端的一種承諾，這種承諾當然是越少越好，越精練越好，過多的承諾帶來的就是你的大量精力和時間去維護！
完！