1. 程式人生 > >一、面向物件的六大原則

一、面向物件的六大原則

        由於部門調整,想換個環境,面試前知識儲備,想對設計模式做個深層瞭解,就看到了書架上那本久久封存的《Android原始碼設計模式解析與實戰》。這本書已經買了一年多了,看了前五章就擱置在那裡,再也沒動過。         設計模式對於開發人員來說並不陌生,但專案中選擇什麼樣的設計模式,如何靈活運用並不是一件易事。接下來,針對這本書,對不同的設計模式做個簡單的介紹。首先從面向物件的六大原則開始,也就是此書中的第一章。

1.單一職責原則(SRP:Single Responsibility Principle

定義:一個類中應該是一組相關性很高的函式、資料的封裝。兩個不一樣的功能不應該放在一個類中。

這個原則沒有具體的劃分界限,需要根據個人經驗,具體業務邏輯而定。這也是優化程式碼的第一步。試想一下,如果所有的功能寫在一個類裡,那麼這個類會越來越大,越來越複雜,越不易修改維護。那麼根據功能,各自獨立拆分出來,豈不是邏輯會清晰些。

比如:我們專案中日誌類、檔案儲存類、常量類等不同的工具類,各司其職。

2.開閉原則(OCP:Open Close Principle

定義:軟體中的物件(類、模組、函式等)應該對於擴充套件是開放的,但是,對於修改是封閉的。

當軟體需要變化時,應該儘量通過擴充套件的方式來實現變化,而不是通過修改已有的程式碼來實現。因為直接的修改,可能會影響已有的正常程式碼,不利於出現錯誤時排除問題。當然實際開發中,修改原有程式碼與擴充套件程式碼是同時存在的。但應儘量以擴充套件為主。

因此,在開發過程中需要自己結合具體情況進行考量,是通過修改舊程式碼還是通過繼承使得軟體系統更穩定、更靈活,在保證去除“程式碼腐化”的同時,也保證原有模組的正確性。

3.里氏替換原則(LSP:Liskov Substitution Principle

第一種定義:如果對每一個型別為S的物件O1,都有型別為T的物件O2,使得以T定義的所有程式P在所有的物件O1都代換成O2時,程式P的行為沒有發生變化,那麼型別S是型別T的子型別。

第二種定義:所有引用父類的地方,必須能使用子類的物件。通俗點講,只要父類能出現的地方子類就可以出現,而且替換為子類也不會產生任何錯誤或異常,使用者可能根本就不需要知道是父類還是子類

,反之,未必可以。

我們知道,面向物件的語言的三大特點是繼承、封裝、多型,里氏替換原則就是依賴於繼承、多型這兩大特性。核心原理:抽象。抽象又依賴於繼承這個特性,在OOP當中,繼承的優缺點都相當明顯。

繼承的優點:

(1)程式碼重用,減少建立類的成本,每個子類都擁有父類的方法和屬性;

(2)子類與父類基本相似,但又與父類有所區別;

(3)提高程式碼的可擴充套件性。

繼承的缺點:

(1)繼承是侵入性的,只要繼承就必須擁有父類的所有屬性和方法;

(2)可能造成子類程式碼冗餘、靈活性降低,因為子類必須擁有父類的屬性和方法。

里氏替換原則就為這類問題提供了指導原則,也就是建立抽象,通過抽象建立規範,具體的實現在執行時替換掉抽象,保證系統的擴充套件性、靈活性。開閉原則和里氏替換原則往往是生死相依、不棄不離的,通過里氏替換來達到對擴充套件開放,對修改關閉的效果。他們都同時強調了一個OOP的重要特性——抽象,因此,在開發過程中運用抽象是走向程式碼優化的重要一步。

4.依賴倒置原則(DIP:Dependence Inversion Principle

定義:指代了一種特定的解耦形式,使得高層次的模組不依賴於低層次的模組的實現細節的目的,依賴模組被顛倒了。他有以下幾個關鍵點:

(1)高層模組不應該依賴低層模組,兩者都應該依賴其抽象;

(2)抽象不應該依賴細節;

(3)細節應該依賴抽象。

解釋:在Java語言中,抽象就是指介面或抽象類,兩者都是不能直接被例項化的;細節就是實現類,實現介面或繼承抽象類而產生的類就是細節,可以直接被例項化,也就是可以加上一個關鍵字new產生一個物件。高層模組就是呼叫端,低層模組就是具體實現類。

依賴倒置原則在 Java語言中的表現就是:模組間的依賴通過抽象發生,實現類之間不發生直接的依賴關係,其依賴關係是通過介面或抽象類產生的。如果類與類直接依賴細節,那麼就會直接耦合,那麼當修改時,就會同時修改依賴者程式碼,這樣限制了可擴充套件性。

5.介面隔離原則(ISP:InterfaceSegregation Principles

定義:客戶端不應該依賴它不需要的介面。

另一種定義:類間的依賴關係應該建立在最小的介面上。

介面隔離原則:將非常龐大、臃腫的介面拆分成更小的和更具體的介面。目的是系統解開耦合,從而容易重構、更改和重新部署。

Bob大叔(Robert C Martin)在21世紀早期將單一職責、開閉原則、里氏替換、介面隔離以及依賴倒置(也稱為依賴反轉)5個原則定義為SOLID原則,作為面向物件程式設計的5個基本原則。當這些原則被一起應用時,它們使得一個軟體系統更清晰、簡單,最大程度地擁抱變化。SOLID被典型地應用在測試驅動開發上,並且是敏捷開發以及自適應軟體開發基本原則的重要組成部分。

6.迪米特原則(LOD:Law of Demeter),也稱為最少知識原則(Least Knowledge Principle)

定義:一個物件應該對其他物件有最少的瞭解。通俗地講,一個類應該對自己需要耦合或呼叫的類知道得最少,類的內部如何實現與呼叫者或者依賴者沒關係,呼叫者或者依賴者只需要知道它需要的方法即可,其他的可一概不用管。這樣使得系統具有更低的耦合與更好的可擴充套件性。

總結:

這六個原則,可以使我們在應用的後續升級、維護中更加方便、輕鬆應對,讓我們的軟體更加靈活。也就意味著在滿足需求且不破壞系統穩定性的前提下保持高可擴充套件性、高內聚、低耦合,在經歷了各版本的變更之後依然保持清晰、靈活、穩定的系統架構。

介紹完面向物件的六大原則,接下來講講設計模式中的第一種模式----單例模式,敬請大家關注!!