文章目錄

• 一. 三大特征的理解
• • • （1）封裝
    • （2）繼承
    • （3）多態
    • （4）面向對象、面向過程的對比
• 二. 七大基本原則的理解
• • • （1）單一職責原則
    • （2）開放封閉原則（OOP 核心）
    • （3）里氏替換原則（OOP 標志）
    • （4）依賴倒置原則
    • （5）接口分離原則
    • （6）迪米特原則（最少知識法則）
    • （7）組合優先繼承原則

拖了好久的總結= =。
對 OOP 的內容零散地看了一些，想了一些還是自己寫一個總結來提升一下理解吧！
學好 OOP，也利于設計模式的學習～
一點自己的見解，疏漏錯誤的地方期待大佬在評論區指正～
文章定義、實例等參考了《大話設計模式》、什么是OOP、OOP七大原則等書籍、文章，感謝～

一. 三大特征的理解

（1）封裝

• 定義：每個對象都包含它能進行操作所需要的所有信息。

• 好處：

• 減少耦合
• 類內部實現可以自由修改
• 類具有清晰的對外接口

• 例子：房子，用墻壁封裝起來。

• 窗戶、門口就是對外接口：設想一下，如果沒有門窗（或者門窗是秘密暗道，不清晰），我們無法進入房子來使用里面的家具，那這個房子還有用嗎？（清晰對外接口的必要性）
• 改變房間布局就是修改類內部：我的房子想怎么改就怎么改，不會給房外人帶來困擾（自由修改內部的體現）
• 減少耦合：我想到的例子是合租；耦合度過高，相當于大家的房子都連在一起（沒有墻壁封裝），耦合度過高帶來的問題，就是不必要的相互聯系：比如我在家用著100寸電視打游戲，你家高三孩子無法避免地看到了，導致無心向學。而墻壁的封裝就可以避免這個不必要的互相聯系，也就是達到減小耦合度的效果。

圖源網絡，侵刪

（2）繼承

• 定義：子類可以理解為對父類的特殊化，除了具備父類特性外，還具備自己的獨立個性。
• 子類擁有父類非 private 的屬性和功能
• 子類具有自己的屬性和功能（拓展）
• 子類可以用自己的方式實現父類的功能（重寫）
• 好處：
• 提高代碼復用率
• 易拓展
• 缺點：父類變，則子類不得不變——繼承會破壞（1）的封裝性。
  可以看到（1）的好處2【自由修改】。顯而易見，繼承會威脅到這一效果：
  父類的自由修改，可能會導致子類出現問題（比如新增抽象函數）。
• 這也顯示著，繼承是一種類與類之間強耦合的關系

因此，有一項“組合優先于繼承”的原則，可以到下面的原則（7）再看一下～

• 例子：雖然大家應該都對繼承熟悉了，不過這邊還是寫一個吧～
  大凡是小凡的爹，因此小明和大明一樣都是黃種人（父類特征）
  雖然是大凡不會rap，但是小凡會（子類拓展）
  大凡唱歌，唱高音；小凡唱歌，唱電音（方法重寫）
  大凡改變膚色，變成黑人，小凡也得變成黑人（破壞封裝性，不能自由修改內部）

  聯動一下計網，URI和URL也可以看成繼承關系噢～（URL 是對 URI 的特殊化）

（3）多態

• 定義：不同對象執行相同動作，但要通過對象自己的代碼執行。
• 子類以父類身份出現（對象聲明必須是父類）
• 子類以自己方式實現（無論對象是否轉換成父類，都用的繼承鏈末端方法）
• 子類特有屬性和方法不可使用
• 優點：提高了代碼的維護性、拓展性
• 例子：這里直接用《大話設計模式》里的例子，這個講的挺好的：
  京劇藝術家大明，和子承父業的兒子小明。父親表演當前生病了，小明代父表演：
  小明穿大明的戲服，以大明的身份進行表演（父類身份）
  小明還是以自己的理解進行表演（自己方式）
  小明雖然說學了一手Breaking，但是父親不會，所以不能使用（特有屬性方法不可用）
• 重載，算多態嗎：按照上面的定義來看，應該不算。但是也有說算是靜態多態的。總的來說應該是看具體定義，看成一種多態應該也是可以的。

（4）面向對象、面向過程的對比

各自相對優點：

• 面向過程：效率更高。（具體化、流程化，不用進行實例化過程）
• 面向對象：易維護、易復用、易擴展。（三大特性）

二. 七大基本原則的理解

誒，網上很多都是五大原則，為了全面點，我這邊還是寫七個的吧～

（1）單一職責原則

• 定義：一個類，應該有且只有一個引起它變化的原因
• 好處
• 耦合度低，變更引起的風險降低，提高可維護性。
• 類的職責明確，增加代碼可讀性。
• 例子：兩種手機類，按照單一職責原則，手機應該只負責通話。
  過多的功能，會提高類的復雜度，同時提高了耦合度。
  （當然，顯示中手機還是按照多種多樣的來的，這里只是想表達一下）

class BadPhone {// 包括手電筒、相機、通話功能的手機類private int flashlightBrightness;private int cameraPixel;private int volume;public void flashlightFunctions() { }public void cameraFunctions() { }public void conversationFunctions() { } }class GoodPhone {// 包括通話功能的手機類private int volume;public void conversationFunctions() { } }

（2）開放封閉原則（OOP 核心）

• 定義：軟件實體，應該是可以拓展，但是不可修改。
• 理解：一個類提供的外部可用接口，如果由于新的需求進行了修改，可能會導致依賴這個接口的其他方法癱瘓。解決方法就是通過拓展新接口，而非修改舊接口來實現新需求。
• 好處：可維護、可拓展、可服用、靈活性好（全包！）
• 例子：getID() 返回 String，printID() 依賴 getID()。現在多了一個返回 int 型 ID 的需求。

class MyClass2 {public String getID() {return "ID";}// Bad // public int getID() { // return 123; // }// Goodpublic int getIntID() {return 123;}public void printID() {// 如果修改 getID()，依賴 getID() 的 printID() 就會出錯// 但是拓展 getIntID()，就沒問題System.out.printf("%s", getID());} }

（3）里氏替換原則（OOP 標志）

• 定義：子類型必須能夠替換掉父類型。
• 優點：保證使用父類的模塊在無需修改的情況下就能拓展，提升拓展性。
• 例子：舉個開槍的例子吧～

class Gun {public void shoot() {System.out.println("fire!");} }class GoodGun extends Gun {@Overridepublic void shoot() {System.out.println("fire! fire!");} }class BadGun extends Gun {@Overridepublic void shoot() {System.out.println("sorry, I can't fire");} }class Man {public void fire() {new Gun().shoot();// new GoodGun().shoot(); 可以替換，能開槍// new BadGun().shoot(); 不能替換，不能開槍} }

（4）依賴倒置原則

• 定義：抽象不應該依賴細節，細節應該依賴于抽象。
• 理解：針對接口，而非實現進行編程。
• 例子：寫一個項目A，用到 Redis（高層模塊項目A，依賴于低層模塊 Redis）。如今由于機子太爛，日常宕機，因此打算換成 etcd 來避免數據丟失的問題。
  問題來了，由于項目A的代碼綁定了 Redis，因此無法復用項目A的代碼，這就問題很大～如何解決呢？如果項目A的代碼依賴的不是Redis，而是抽象的 K-V 數據庫，具有穩定的接口（也就是依賴于抽象），那就可以直接替換成 etcd 啦～

講道理，我不會 Redis、etcd，這里的例子是大概舉出來的，有誤的話歡迎指出～

（5）接口分離原則

• 定義：客戶端不應該依賴它不需要的接口。采用多個與特定客戶類有關的接口，比采用一個通用的接口要好。
• 理解：相對于（1）單一職責原則（注重業務邏輯劃分），這里要求的是接口的方法盡量少
• 好處：
• 避免接口污染
• 高內聚（一個軟件模塊是由相關性很強的代碼），畢竟用多個合適接口啦～
• 靈活性
• 例子：實現老人機類，一個復雜的手機接口 VS 多個簡單的功能接口

interface BadPhoneInterface {void fly();void swim();void watchTV();void buy();void talk();void sendMessage(); }// 老人機：只希望能打電話、發短信就好 // 非接口分離：采用了具有多個方法的接口，并非高聚合 class OldPhone1 implements BadPhoneInterface {@Overridepublic void fly() { }@Overridepublic void swim() { }@Overridepublic void watchTV() { }@Overridepublic void buy() { }@Overridepublic void talk() { }@Overridepublic void sendMessage() { } }// 接口分離：高聚合，靈活，定制化～ interface Talker {void talk(); }interface MessageSender {void sendMessage(); }class OldPhone2 implements Talker, MessageSender {@Overridepublic void talk() { }@Overridepublic void sendMessage() { } }

（6）迪米特原則（最少知識法則）

• 定義：如果兩個類不必彼此直接通信，那么這兩個類就不應該發生直接的相互作用。如果其中一個類需要調用另一個類的某一個方法，可以通過第三者轉發調用。
• 理解：根本思想是強調類之間的松耦合，促進了類的復用
• 例子：秋招時節～舉一個求職例子吧！（當然，具體面試流程肯定沒我瞎寫的這么糙）
  小紅想進大廠A，于是花了大功夫認識了面試官1投簡歷，希望面試官1過幾天能面她。
  但是～還沒來得及面，面試官1就跳槽了！那小紅接下來該怎么辦，繼續花大時間來找面試官2、面試官3嗎？這就是沒有遵循迪米特原則了：
  小紅和（具體）面試官之間，不應該有直接的聯系，這樣耦合太高了。而應該是找HR！讓HR來充當這個轉發“求面試調用”的第三者，這樣耦合度低，而且不會發生像上面那樣的事情了^ ^

（7）組合優先繼承原則

• 定義：能用組合的地方就不要繼承，以保證封裝性。

  （6）(7）的代碼有空再補了。。敲累了擺爛
  花了一下午我是沒想到的= =
  希望這個總結能幫助讀者有更多的OOP理解，感謝你能閱讀到這里～

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的【总结记录】面向对象设计OOP三大特性（封装、继承、多态）、七大基本原则的理解（结合代码、现实实例理解）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。