初探面向對象編程之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 接口隔離原則

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

完!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章