任何一個有趣、有用的程式、項目或者游戲，都需要堅實的基本功方能實現，設計模式就是我們必學的基本功。 ...
學編程，總是逃不了要學“演算法”，也總跳不開要學“設計模式”。
無論學習什麼語言，設計模式始終是我們必須掌握的，這是程式員的基本功。
設計模式（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>
這樣，在業務規則發生改變的情況下，我們通過拓展子類及修改持久層(高層次模塊)便足以應對多變的需求。開閉原則要求我們儘可能通過拓展來實現變化，儘可能少地改變已有模塊，特別是底層模塊。
開閉原則總結：
- 提高代碼復用性
- 提高代碼的可維護性
本課不像其他項目實戰課程那般，相對晦澀難懂，不那麼富有趣味性，但任何一個有趣、有用的程式、項目或者游戲，都需要堅實的基本功方能實現，設計模式就是我們必學的基本功。
“每一棟大廈，都從一塊磚開始”
