|
| 1 | +# golang-explicity-check-interface-implementation |
| 2 | + |
| 3 | +這個 repository 主要用來示範。如何透過語法宣告的方式,讓 golang compiler 能夠在編譯時期就檢查出 struct 是否有實做介面所宣告 receiver 方法 |
| 4 | + |
| 5 | +## 說明 |
| 6 | + |
| 7 | +當今天需要針對很多種不同變量具有類似的介面,可以透過定義出一個介面共同規範出在 struct 的 receiver 方法。比如說處理檔案的方法,可能會有針對不同檔案比如說 csv 檔案類型, excel 檔案類型。這時為了之後在處理檔案這個方法可以方便擴充,可以針對要處理檔案的型別都需要具有一個處理檔案的方法 FileProcessor ,則可以透過介面定義到 fileprocessor.go 檔案如下: |
| 8 | + |
| 9 | +```golang |
| 10 | +type FileProcessor interface { |
| 11 | + ParseLines(content string) ([]string, error) |
| 12 | +} |
| 13 | +``` |
| 14 | + |
| 15 | +假設今天要實做一個處理 CSV 檔案的型別 CSVProcessor ,則我們可以實做 FileProcessor 介面定義的 Receiver到 csvprocessor.go 如下: |
| 16 | + |
| 17 | +```golang |
| 18 | +type CSVProcessor struct{} |
| 19 | + |
| 20 | +func (c *CSVProcessor) ParseLines(content string) ([]string, error) { |
| 21 | + lines := strings.Split(strings.TrimSpace(content), "\n") |
| 22 | + return lines, nil |
| 23 | +} |
| 24 | +``` |
| 25 | + |
| 26 | +這時在定義 ProcessFile 時,就可以根據不同的檔案。來傳入有實做 ParseLines 介面的型別了到 main.go 如下: |
| 27 | + |
| 28 | +```golang |
| 29 | +func ProcessFile(p FileProcessor, content string) ([]string, error) { |
| 30 | + return p.ParseLines(content) |
| 31 | +} |
| 32 | + |
| 33 | +func main() { |
| 34 | + csv := &CSVProcessor{} |
| 35 | + csvResult, err := ProcessFile(csv, "name,age\nAlice,30\nBob,25") |
| 36 | + if err != nil { |
| 37 | + fmt.Println(err) |
| 38 | + return |
| 39 | + } |
| 40 | + fmt.Println(csvResult) |
| 41 | +} |
| 42 | +``` |
| 43 | + |
| 44 | +然而,如果今天實做 CSVProcessor 型別的人,因為如果擴充去對 ParseLines 新增一個參數 amount 假設如下 |
| 45 | + |
| 46 | +```golang |
| 47 | +func (c *CSVProcessor) ParseLines(content string, amount int) ([]string, error) { |
| 48 | + lines := strings.SplitN(strings.TrimSpace(content), "\n", amount) |
| 49 | + return lines, nil |
| 50 | +} |
| 51 | +``` |
| 52 | + |
| 53 | +這時,會發現除了調用方會發現傳入的型別有錯,實做 CSVProcessor 型別的人,不會發現自己破壞了原本 ParseLines 的 Receiver 方法直到要運行時,才發現調用出錯。 |
| 54 | + |
| 55 | +## 有一個方法可以讓這個錯誤很快在實做 CSVProcessor 型別檢查是否有實做了 FileProcessor 介面定義的 receiver 方法 |
| 56 | + |
| 57 | +變更 csvprocessor.go 如下 |
| 58 | +```golang |
| 59 | +type CSVProcessor struct{} |
| 60 | + |
| 61 | +var _ FileProcessor = (*CSVProcessor)(nil) |
| 62 | + |
| 63 | +func (c *CSVProcessor) ParseLines(content string, amount int) ([]string, error) { |
| 64 | + lines := strings.SplitN(strings.TrimSpace(content), "\n", amount) |
| 65 | + return lines, nil |
| 66 | +} |
| 67 | +``` |
| 68 | + |
| 69 | +顯示如下: |
| 70 | + |
| 71 | + |
| 72 | +語法解析 |
| 73 | +```golang |
| 74 | +// 把 nil 轉換成 (*CSVProcessor) 型別指定給 FileProcessor 有時作介面的變數 |
| 75 | +var _ FileProcessor = (*CSVProcessor)(nil) |
| 76 | +``` |
| 77 | + |
| 78 | +加入這行之後,不會增加 compiler 之後的大小。但會強迫 compiler 去檢查 CSVProcessor 是否有時作 FileProcessor 介面定義的 receiver |
| 79 | + |
| 80 | +為了簡化說明,我把此作法稱為**顯性宣告**。 |
| 81 | + |
| 82 | +## 顯性宣告的優點 |
| 83 | + |
| 84 | +方便在實做的型別處,有編譯器檢查是否具實做介面定義的 receiver。 |
| 85 | + |
| 86 | +## 顯性宣告的缺點 |
| 87 | + |
| 88 | +當介面足夠單純,不會有變更時。這個宣告顯的多餘一點。 |
| 89 | + |
| 90 | +## 結論 |
| 91 | + |
| 92 | +大部分時候,顯性宣告具有約束力的好處。 |
0 commit comments