設計模式——設計原則

2019-11-10 20:45:48

字體：大中小

來源：轉載

供稿：網友

面向對象原則、OOD和OOP概述

面向對象原則和OOD實際上是兩個不同的方面。

面向對象原則：封裝、繼承、多態。

OOP指的是面向對象編程的基本原則和核心思路。在這里，OOP可以比作英語基礎語法，這些語法教你如何用單詞構造有意義且正確的句子，OOP教你在代碼中構造類，并在類里封裝屬性和方法，同時構造他們之間的層次關系。

現在假定你需要就某些主題寫幾篇文章或隨筆。你也希望就幾個你擅長主題寫幾本書。對寫好文章/隨筆或書來說，知道如何造句是不夠的。為了使讀者能更輕松的明白你講的內容，你需要寫更多的內容，學習以更好的方式解釋它。如果你想就某個主題寫一本書，如學習OOD，你知道如何把一個主題分為幾個子主題。你需要為這些題目寫幾章內容，也需要在這些章節中寫前言，簡介，例子和其他段落。你需要為寫個整體框架，并學習一些很好的寫作技巧以便讀者能更容易明白你要說的內容。這就是整體規劃。

在軟件開發中，OOD是整體思路。在某種程度上，設計軟件時，你的類和代碼需能達到模塊化，可復用，且靈活，這些很不錯的指導原則不用你重新發明創造。而且有些原則你在自己的代碼中可能用到了。

為什么要OOD?

軟件開發唯一的真理是“軟件一定會變化”。為什么?因為你的軟件解決的是現實生活中的業務問題，而現實生活中的業務流程總是在不停的變化。

假設你的軟件在今天工作的很好。但它能靈活的支持“變化”嗎?如果不能，那么你就沒有一個設計敏捷的軟件（一個設計敏捷的軟件能輕松應對變化，能被擴展，并且能被復用）。并且應用好OOD是做到敏捷設計的關鍵。

做到OOD的代碼需要滿足的條件：

1、面向對象

2、復用

3、能以最小的代價滿足變化

4、不用改變現有代碼滿足擴展

OOD最基本的原則

最基本的是叫做SOLID的5原則(感謝Uncle Bob,偉大OOD導師)。

S = 單一職責原則 Single Responsibility PRinciple

O = 開放閉合原則 Opened Closed Principle

L = Liscov替換原則 Liscov Substitution Principle

I = 接口隔離原則 Interface Segregation Principle

D = 依賴倒置原則 Dependency Inversion Principle

單一職責原則 Single Responsibility Principle

單一職責原則海報

海報上說："并不是因為你能，你就應該做"。為什么?因為長遠來看它會帶來很多管理問題。

從面向對象角度解釋為："引起類變化的因素永遠不要多于一個。"或者說"一個類有且只有一個職責"。這個原則是說，如果你的類有多于一個原因會導致它變化(或者多于一個職責)，你需要依據它們的職責把這個類拆分為多個類。

當然可以在一個類中包含多個方法。問題是，他們都是為了一個目的。如今為什么拆分很重要?

那是因為：

1、每個職責是軸向變化的;

2、如果類包含多個職責，代碼會變得耦合;

看一下下面的類層次。

違反單一職責原則的類結構圖

這里，Rectangle類做了下面兩件事：

1、計算矩形面積;

2、在界面上繪制矩形;

并且，有兩個應用使用了Rectangle類：

1、計算幾何應用程序用這個類計算面積;

2、圖形程序用這個類在界面上繪制矩形;

Rectangle類做了兩件事。在一個方法里它計算了面積，在另外一個方法了它返回一個表示矩形的GUI。這會帶來一些有趣的問題：

1.在計算幾何應用程序中我們必須包含GUI。也就是在開發幾何應用時，我們必須引用GUI庫;

2.圖形應用中Rectangle類的變化可能導致計算幾何應用變化，編譯和測試，反之亦然;

應該依據職責拆分這個類，拆分職責到兩個不同的類中，如：

Rectangle:這個類應該定義Area()方法;

RectangleUI:這個類應繼承Rectangle類，并定義Draw()方法。

SRP是把事物分離成分子部分，以便于能被復用和集中管理。我們也可以把SRP應用到方法之中，應當分解你的方法，讓每個方法只做某一項工作。那樣允許你復用方法，并且一旦出現變化，你能購以修改最少的代碼滿足變化。

開放閉合原則 Opened Closed Principle

從面向對象設計角度看,它可以這么說:"軟件實體(類,模塊,函數等等)應當對擴展開放，對修改閉合。"

通俗來講，它意味著你應當能在不修改類的前提下擴展一個類的行為。就好像我不需要改變我的身體而可以穿上衣服。

客戶端和服務段都耦合在一起。那么，只要出現任何變化，服務端變化了，客戶端一樣需要改變。

在這個例子中，添加了一個抽象的服務器類，客戶端包含一個抽象類的引用，具體的服務類實現了抽象服務類。那么，因任何原因引起服務實現發生變化時，客戶端都不需要任何改變。

這里抽象服務類對修改是閉合的，實體類的實現對擴展是開放的。

抽象是關鍵，基本上，你抽象的東西是你系統的核心內容，如果你抽象的好，很可能在擴展功能時它不需要任何修改(就像服務是一個抽象概念)。如果在實現里定義了抽象的東西(比如IIS服務器實現的服務)，代碼要盡可能以抽象(服務)為依據。這會允許你擴展抽象事物，定義一個新的實現(如Apache服務器)而不需要修改任何客戶端代碼。

Liscov替換原則 Liscov Substitution Principle

這個原則意思是："子類型必須能夠替換它們父類型。"或者換個說法："使用父類引用的函數必須能使用子類的對象而不必知道它。"

在基本的面向對象原則里，"繼承"通常是"is a"的關系。如果"Developer" 是一個"SoftwareProfessional",那么"Developer"類應當繼承"SoftwareProfessional"類。在類設計中"Is a"關系非常重要，但它容易沖昏頭腦，結果使用錯誤的繼承造成錯誤設計。

"Liskov替換原則"正是保證繼承能夠被正確使用的方法。

這里，KingFisher類擴展了Bird基類，并繼承了Fly()方法，這看起來沒問題。

現在看下面的例子：

Ostrich(鴕鳥)是一種鳥(顯然是),并從Bird類繼承。它能飛嗎?不能，這個設計就違反了LSP。

所以，即使在現實中看起來沒問題，在類設計中，Ostrich不應該從Bird類繼承，這里應該從Bird中分離一個不會飛的類，Ostrich應該繼承與它。

為什么LSP這么重要：

如果沒有LSP，類繼承就會混亂;如果子類作為一個參數傳遞給方法，將會出現未知行為;

如果沒有LSP，適用與基類的單元測試將不能成功用于測試子類;

接口隔離原則 Interface Segregation Principle

它的意思是："客戶端不應該被迫依賴于它們不用的接口。"

假設你想買個電視機，你有兩個選擇。一個有很多開關和按鈕，它們看起來很混亂，且好像對你來說沒必要。另一個只有幾個開關和按鈕，它們很友好，且適合你使用。假定兩個電視機提供同樣的功能，你會選哪一個?答:第二個，因為我不需要那些看起來混亂又對我沒用的開關和按鈕。

以便外部能夠知道這些類有哪些可用的功能,客戶端代碼也能根據接口來設計.現在,如果接口太大,包含很多暴露的方法,在外界看來會很混亂.接口包含太多的方法也使其可用性降低,像這種包含了無用方法的"胖接口"會增加類之間的耦合.你通過接口暴露類的功能,同樣地,假設你有一些類,如果一個類想實現該接口,那么它需要實現所有的方法,盡管有些對它來說可能完全沒用.所以說這么做會在系統中引入不必要的復雜度,降低可維護性或魯棒性.

接口隔離原則確保實現的接口有他們共同的職責,它們是明確的,易理解的,可復用的.

接口應該僅包含必要的方法,而不該包含其它的。

注意到IBird接口包含很多鳥類的行為,包括Fly()行為.現在如果一個Bird類(如Ostrich)實現了這個接口，那么它需要實現不必要的Fly()行為(Ostrich不會飛).

所以，這個"胖接口"應該拆分未兩個不同的接口，IBird和IFlyingBird,IFlyingBird繼承自IBird.

這里如果一種鳥不會飛(如Ostrich)，那它實現IBird接口。如果一種鳥會飛(如KingFisher)，那么它實現IFlyingBird.

所以回頭看包含了很多開關和按鈕的電視機的例子，電視機制造商應該有一個電視機的圖紙，開關和按鈕都在這個方案里。不論任何時候，當他們向制造一種新款電視機時，如果他們想復用這個圖紙，他們將需要在這個方案里添加更多的開關和按鈕。那么他們將沒法復用這個方案。如果他們確實需要復用方案，它們應當把電視機的圖紙份為更小部分，以便在任何需要造新款電視機的時候復用這點小部分。