設計模式：程式員跳不開的坑-有解無憂

學編程，總是逃不了要學“演算法”，也總跳不開要學“設計模式”，

無論學習什么語言，設計模式始終是我們必須掌握的，這是程式員的基本功，

設計模式（Design pattern）是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結，

使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性，毫無疑問，設計模式于己于他人于系統都是多贏的，設計模式使代碼編制真正工程化，設計模式是軟體工程的基石，如同大廈的一塊塊磚石一樣，

專案中合理的運用設計模式可以完美的解決很多問題，每種模式在現在中都有相應的原理來與之對應，每一個模式描述了一個在我們周圍不斷重復發生的問題，以及該問題的核心解決方案，這也是它能被廣泛應用的原因，

今天給大家推薦的新課《Go 語言實作 23 種設計模式》，教程涉及7大設計原則、23種設計模式，每種設計模式都從定義、應用及Golang實體三個部分進行詳細介紹，

本課需要學員對 Go 語言有一定的基礎哦，可先學習《Go 語言簡明教程》之后再來學習本課，

本課程概念較多，受篇幅限制，不宜放過多文字，下面截取課程第一章內容給大家介紹第1種設計原則——開閉原則的概念，想要學習完整設計原則及設計模式的小伙伴請移步至《Go 語言實作 23 種設計模式》學習整個課程，

開閉原則

開閉原則(Open Closed Principle，OCP) 由勃蘭特.梅耶(Bertrand Meyer)提出，他在 1988 年的著作《面向物件軟體構造》( Object Oriented Software Construction)中提出：軟體物體應當對擴展開放，對修改關閉(Software entities should be open for extension, but closed for modification)，這就是開閉原則的經典定義，

開閉原則是設計模式中的總原則，開閉原則就是說:對拓展開放、對修改關閉，模塊應該在盡可能不修改代碼的前提下進行拓展，這就需要使用介面和抽象類來實作預期效果，我們舉例說明什么是開閉原則，以 4s 店銷售汽車為例，其類圖如圖所示：

ICar 介面定義了汽車的兩個屬性：名稱和價格，BenzCar 是一個奔馳車的實作類，代表奔馳車的總稱，Shop4S 代表售賣的 4S 店，ICar 介面的代碼清單如下：

<pre> package main
 import "fmt"
 type ICar interface {
 // 車名
 GetName() string
 // 價格
 GetPrice() int
 }
 copy</pre>

一般情況下 4S 店只出售一種品牌的車，這里用奔馳為例，代碼清單如下

<pre> type BenzCar struct {
    name string
    price int
 }
 func (b BenzCar) GetName() string {
    return b.name
 }
 func (b BenzCar) GetPrice() int {
    return b.price
 }
 copy</pre>

這里我們模擬一下 4s 店售車記錄：

<pre> func main() {
    var (
        list []ICar
    )
    list = []ICar{}
    list = append(list,&BenzCar{"邁巴赫",130})
    list = append(list,&BenzCar{"AMG",343})
    list = append(list,&BenzCar{"V",60})
    for _,v := range list {
        fmt.Println("車名:",v.GetName(),"\t價格:",v.GetPrice())
    }
 }
 copy</pre>

接下來，我們在命令列中輸入 cd Principle 先切換到 go 檔案所在目錄下，然后執行 go run 1.go 來看我們的執行結果，如下圖所示：

暫時來看，以上設計是沒有啥問題的，但是，某一天，4s 店老板說奔馳轎車統一要收取一筆金融服務費，收取規則是價格在 100 萬元以上的收取 5%，50~100 萬元的收取 2%，其余不收取，為了應對這種需求變化，之前的設計又該如何呢?

目前，解決方案大致有如下三種：

修改 ICar 介面：在 ICar 介面上加一個 getPriceWithFinance 介面，專門獲取加上金融服務費后的價格資訊，這樣的后果是，實作類 BenzCar 也要修改，業務類 Shop4S 也要做相應調整，ICar 介面一般應該是足夠穩定的，不應頻繁修改，否則就失去了介面鍥約性了，
修改 BenzCar 實作類：直接修改 BenzCar 類的 getPrice 方法，添加金融服務費的處理，這樣的一個直接后果就是，之前依賴 getPrice 的業務模塊的業務邏輯就發生了改變了，price 也不是之前的 price 了，
使用子類拓展來實作：增加子類 FinanceBenzCar，覆寫父類 BenzCar 的 getPrice 方法，實作金融服務費相關邏輯處理，這樣的好處是：只需要調整 Shop4S 中的靜態模塊區中的代碼，main 中的邏輯是不用做很大的修改的，

新增的 FinanceBenzCar 類代碼清單如下:

<pre> type FinanceBenzCar struct {
    BenzCar
 }
 func (b FinanceBenzCar) GetPrice() int {
    // 獲取原價
    selfPrice := b.price
    var finance int
    if selfPrice >= 100 {
        finance = selfPrice + selfPrice5/100    } else if selfPrice >= 50 {        finance = selfPrice + selfPrice2/100
    } else {
        finance = selfPrice
    }
    return finance
 }
 copy</pre>

主函式：

<pre> func main() {
    var (
        list []ICar
    )
    list = []ICar{}
    list = append(list,&FinanceBenzCar{BenzCar{"邁巴赫",99}})
    list = append(list,&FinanceBenzCar{BenzCar{"AMG",200}})
    list = append(list,&FinanceBenzCar{BenzCar{"V",40}})
    for _,v := range list {
        fmt.Println("車名:",v.GetName(),"\t價格:",v.GetPrice())
    }
 }
 copy</pre>

測驗結果

<pre> === RUN   TestBenzCar_GetName
 車名: 邁巴赫     價格: 100
 車名: AMG     價格: 210
 車名: V     價格: 40
 --- PASS: TestBenzCar_GetName (0.00s)
 PASS
 copy</pre>

這樣，在業務規則發生改變的情況下，我們通過拓展子類及修改持久層(高層次模塊)便足以應對多變的需求，開閉原則要求我們盡可能通過拓展來實作變化，盡可能少地改變已有模塊，特別是底層模塊，

開閉原則總結：

提高代碼復用性
提高代碼的可維護性

本課不像其他專案實戰課程那般，相對晦澀難懂，不那么富有趣味性，但任何一個有趣、有用的程式、專案或者游戲，都需要堅實的基本功方能實作，設計模式就是我們必學的基本功，

“每一棟大廈，都從一塊磚開始”

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/8588.html

標籤：設計模式

上一篇：設計模式之單例模式

下一篇：設計模式之工廠模式