檢舉內容
Unity C# | 物件導向五大設計原則(SOLID)

2023/01/25閱讀時間約 5 分鐘

前言

  這篇文章將會介紹五大物件導向守則。

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

  強調「當設計封裝一個類別時,該類別只負責一件事」。這與類別抽象化的過程中,對於該類別應該負責那些功能有關。一個類別應該只負責系統中一個單獨功能的實作,但對於功能的切分及歸屬,通常也是開發過程中最困擾設計者的。

現象 | 累加再累加

  設計師一開始不太容易實現這個原則,在專案開發的過程中,不斷地往同一個類別上增加功能,最後導致類別過於龐大、介面過於複雜後才會發現問題。

建議 | 類別重構

  將類別中與實作相關功能的部分抽取出來,另外封裝維新的類別,之後再利用組合的方式將新增的類別加入原類別之中,慢慢地就能達成單一職責化的需求。

2. 開放封閉原則(OPC:Open-Closed Priciple)

  類別要「對外擴充開放、對修改關閉」。類別是實作系統某項功能的類別。當軟體的開發流程進入「完工測試」時,對於已經完成或上線的功能,就應該「關閉修改的需求」,當增加系統功能的需求發生,就要對「功能的增加保持開放」。

建議 | 功能介面化

  將系統功能的「操作方法」向上提升,抽象畫為「介面」,將「功能的實作」往下一到子類別中。
  1. 重新實作一個新的子類別。
  2. 繼承舊有的實作類別,並在新的子類別中實作新增的系統功能。

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

  指「子類別必須能夠替換父類別」。如果按造這個設計原則去實作一個有多層繼承的類別群組,那麼當中的父類別通常是「介面類別」或是「可被繼承的類別」。
  父類別中醫定包含了可被子類別重新實作的方法,而客戶端使用的操作介面也由父類別來定義。客戶端在使用過程中,必須不能使用到「物件強制轉型為子類別」的語法,客戶端也不應該知道,現在使用的物件是哪一個子類別實作。
  使用哪個子類別的物件來替代父物件類別,則是由類別本身的物件產生機制來決定,外界無法得知。

4. 相依性反向原則(DIP:Dependence Inversion Principle)

此原則包含兩個主題。
  • 高層模組不應該相依於低層模組,兩者都應該相依於抽象概念。
  • 抽象介面部應該相依於實作,而實作應該相依於抽象介面。

介紹 | 汽車

  汽車就是所謂的高層模組,它由引擎系統、傳動系統、懸吊系統、車身骨架系統、電裝系統等,有了低層模組的相互配合才完成一部汽車。
  然而汽車卻很容易被引擎給限定,也就是說,裝載無鉛汽油的汽車不能使用柴油做為燃料;裝載柴油引擎的汽車不能使用無鉛汽油作為燃料,這就是「高階模組相依於低層模組」的例子。

介紹 | 個人電腦

  電腦是高層模組,定義了 USB 介面,這個介面定義了硬體鎖需的規格及軟體驅動程式的撰寫規格,任何底層模組(記憶卡、隨身碟、讀卡機、相機、手機等)都能加入個人電腦的模組中。

總結 | 相依反轉

  在個人電腦中,高層模組定義介面,低層模組再依照這個介面實作,這個過程可以讓他們之間的相依關係反轉,不用像汽車那樣被限制,同時也說明了「抽象介面部應該相依於實作,而實作應該相依於抽象介面」。
  當高層模組定義好介面之後,底層模組的溝通就只能藉由介面來進行,這個介面可以是一個類別的變數或物件參考。

5. 介面分割原則(ISP:Interface Segregation Principle)

  這是在解決「客戶端不應該被迫使用他們用不到的介面方法」,這個問題一般隨著專案開發的進行而越來越明顯:
  當專案中出現了一個負責主要功能的類別,而且這個類別還必須負責跟其他子系統做溝通時,針對每一項子系統的需求,主要類別就必須增加對應的方式,越多的方法就等同增加類別的介面複雜度。

建議 | 介面分割

  透過「功能的切分」及「介面的簡化」可以減少這類問題的發生,或是套用設計模式來重新規劃類別,也可以減少不必要的操作介面出現在類別中。

常用的其他原則

  這裡收納兩個常用的其他原則。

最少知識原則(LKP:Least Knowledge Principle)

  當實作一個類別,這個類別應該越少使用到其他類別提供的功能越好,也就是說當個類別能夠只依照本身的「知識」去完成功能,就相對減少與其它物件「知識」的依賴程度。
這樣有兩個好處:
  1. 減少此類別與其他類別的耦合度。
  2. 增加被其他專案共用的可能性。

少用繼承多用組合

  當子類別繼承一個「介面類別」後,新的子類別就要負責重新設計實作介面類別中所定義的方法,而且不該額外擴充介面,以符合上述多個設計原則的需求。
  然而讓子類別繼承舊有的實作類別,卻也是最容易的實現方法之一,在子類別內增加想要擴充的「功能方法」並加以實作,客戶端之後就能直接利用子類別物件進行新增功能的呼叫。
  例如,鬧鐘類別可利用繼承「時鐘類別」的方式,取得「時間功能」的實作,只要子類別加上定時提醒的功能,就能達成鬧鐘功能的目標,然而客戶端使用鬧鐘類別時,對於取得目前時間沒有需求,只是單純想設定鬧鐘時間而已。

建議 | 宣告類別

在鬧鐘的類別定義中,宣告一個型別為時鐘類型的「類別成員」,那麼就可以減少不必要的方法出現在鬧鐘介面上,也可以減少鬧鐘類別的客戶端對時中類別的相依性。

後記

  這篇文章是我之前的一個筆記,關於物件導向五大基本原則,了解這些後對於程式設計想當有幫助。

瓶裝雪

參考資料

贊助創作者百元,就抽 $8,888 紅包與好禮!
設計資歷越久,越能感到設計的龐大與通用性」在2020年9月,我成為一名大學生,在經營方格子的同時,往設計師邁進,未來希望專攻遊戲程式與企劃。
對設計師如何成長為設計師好奇嗎? 2020年九月,我進入大學學習當一位設計師,從開始到沉寂,再到重燃熱忱,我將在方格子紀錄我的成長歷程、理念、心情,分享我在這段旅程中所經歷的故事。
如果要發表留言,請先登入註冊會員
打造你的創作天地
在這裡尋找共鳴,與方格子的 35 萬格友分享觀點與生活。
領取見面禮
只要設定追蹤作者,即可享有 48小時
Premium 閱讀權限