初探面向對象編程之oop與設計模式

1. 編程方式

咱們目前的編程方式大致能夠有如下三種編程方式：

• 順序編程

• 過程式編程

• 面向對象編程

在講面向對象編程時先講一下什麼是順序編程，什麼是過程式編程，什麼是面向對象編程：

1. 順序編程： 就是隻用一個單線程去執行一段代碼，執行過程根據代碼依次從上到下按順序執行各類指令操做

2. 過程式編程：過程式的編程中心是圍繞着代碼，好比當程序執行到某一個位置的時候回調用一個其餘的方法來實現剩餘的業務邏輯，而後程序繼續往下執行，這就是過程式編程。通俗一點使用函數的方式來編寫代碼都屬於過程式編程，更深層次的，例如某些PHP開發者雖然使用了類的概念來寫程序，可是仍是區域過程式的方式編程，doris周圍的大多數同事就是如此，包括doris在瞭解面向對象編程以前也一樣採用過程式的方式寫程序。

3. 面向對象編程：通俗的講就是就是在寫程序時，咱們程序員本身設計出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 接口隔離原則

這個原則的意思是：使用多個專門的接口比使用單個接口要好的多！爲了減小接口的定義，將許多相似的方法都放在一個接口中，最後發現，維護和實現接口的時候花了太多精力，而接口所定義的操做至關於對客戶端的一種承諾，這種承諾固然是越少越好，越精練越好，過多的承諾帶來的就是你的大量精力和時間去維護！

完！