1. 程式人生 > 其它 >面向物件的三大基本特徵,五大基本原則

面向物件的三大基本特徵,五大基本原則

面向物件的三大基本特徵,五大基本原則
目錄

一、三大基本特徵:封裝、繼承、多型
      1、封裝
      2、繼承
      3、多型
  二、五大基本原則
      1、單一職責原則(SRP)
      2、開放封閉原則(OCP)
      3、里氏替換原則(LSP)
      4、依賴倒置原則(DIP)
      5、介面隔離原則(ISP)
  網上的講解很多,但大都類似,這裡進行轉載整理。三大基本特徵是理解五大基本原則的前提。

一、三大基本特徵:封裝、繼承、多型
  1、封裝
  封裝就是隱藏物件的屬性和實現細節,僅對外公開介面,控制在程式中屬性的讀和修改的訪問級別,將抽象得到的資料和行為(或功能)相結合,形成一個有機的整體,也就是將資料與操作資料的原始碼進行有機的結合,形成“類”,其中資料和函式都是類的成員。

  封裝的目的是增強安全性和簡化程式設計,使用者不必瞭解具體的實現細節,而只是要通過外部介面,以特定的訪問許可權來使用類的成員。

  面相物件的不就是使用程式處理事情時以物件為中心去分析嗎,與面向過程不同,面向過程關心處理的邏輯、流程等問題,而不關心事件主體。而面向物件即面向主體,所以我們在解決問題時應該先進行物件的封裝(物件是封裝類的例項,比如張三是人,人是一個封裝類,張三隻是物件中的一個例項、一個物件)。比如我們日常生活中的小兔子、小綿羊都可以封裝為一個類。

   

  比如兔子的屬性有兩隻耳朵、四隻腿、一雙眼睛、三瓣嘴等;行為(功能)有跑、跳、吃素等。

  2、繼承
  繼承是面向物件的基本特徵之一,繼承機制允許建立分等級層次的類。繼承就是子類繼承父類的特徵和行為,使得子類物件(例項)具有父類的例項域和方法,或子類從父類繼承方法,使得子類具有父類相同的行為。類似下面這個圖:

  

  我們在上面已經封裝了兔子這個類,其他動物也一樣可以進行封裝。在封裝過程中我們發現兔子、綿羊這兩個類具有相似的功能或特性如吃草,所以我們可以抽取共有特徵和方法形成高一層的類,如這裡的食草動物、食肉動物。繼承之間是子父類的關係。繼承機制可以很好的描述一個類的生態,也提高了程式碼複用率,在Java中的Object類是所有類的超類,常稱作上帝類。

  3、多型
  多型同一個行為具有多個不同表現形式或形態的能力。是指一個類例項(物件)的相同方法在不同情形有不同表現形式。多型機制使具有不同內部結構的物件可以共享相同的外部介面。這意味著,雖然針對不同物件的具體操作不同,但通過一個公共的類,它們(那些操作)可以通過相同的方式予以呼叫。

  多型的優點:

  1. 消除型別之間的耦合關係
  2. 可替換性
  3. 可擴充性
  4. 介面性
  5. 靈活性
  6. 簡化性
      多型存在的三個必要條件:

繼承
重寫(子類繼承父類後對父類方法進行重新定義)
父類引用指向子類物件
  簡言之,多型其實是在繼承的基礎上的。比如說今天我們要去動物園參觀動物,那麼你說我們去參觀兔子、參觀綿羊、參觀獅子、參觀豹子都是對的,但你不能說我們去參觀汽車。在這個例子中,子類具有多型性:除了使用自己的身份,還能充當父類。

二、五大基本原則
  1、單一職責原則(SRP)
  一個類應該有且只有一個去改變它的理由,這意味著一個類應該只有一項工作。

  比如在職員類裡,將工程師、銷售人員、銷售經理這些情況都放在職員類裡考慮,其結果將會非常混亂,在這個假設下,職員類裡的每個方法都要if else判斷是哪種情況,從類結構上來說將會十分臃腫。

  2、開放封閉原則(OCP)
  物件或實體應該對擴充套件開放,對修改封閉。

  更改封閉即是在我們對模組進行擴充套件時,勿需對源有程式程式碼和DLL進行修改或重新編譯檔案!這個原則對我們在設計類的時候很有幫助,堅持這個原則就必須儘量考慮介面封裝,抽象機制和多型技術!

  3、里氏替換原則(LSP)
  在物件 x 為型別 T 時 q(x) 成立,那麼當 S 是 T 的子類時,物件 y 為型別 S 時 q(y) 也應成立。(即對父類的呼叫同樣適用於子類)

  4、依賴倒置原則(DIP)
  高層次的模組不應該依賴於低層次的模組,他們都應該依賴於抽象。具體實現應該依賴於抽象,而不是抽象依賴於實現。

  可以這樣理解,上面我舉例子的時候先說了兔子和綿羊,然後才推出食草動物。但如果我們繼續認識了牛、馬等食草動物,我們會發現我們需要不斷調整食草動物的描述,這樣程式會變得僵化,所以我們不應該讓子類依賴於實體,不應該讓父類模組依賴於子類模組。所以我們需要將食草動物設計為抽象類,即抽象類或介面。這樣下層只需要實現相應的細節而不會影響父類。

  5、介面隔離原則(ISP)
  不應強迫客戶端實現一個它用不上的介面,或是說客戶端不應該被迫依賴它們不使用的方法,使用多個專門的介面比使用單個介面要好的多!

  比如,為了減少介面的定義,將許多類似的方法都放在一個介面中,最後會發現,維護和實現介面的時候花了太多精力,而介面所定義的操作相當於對客戶端的一種承諾,這種承諾當然是越少越好,越精練越好,過多的承諾帶來的就是你的大量精力和時間去維護!

注:該文章來自於風之之