那么我們想編出一些泛化的方法和接口，怎么辦呢？ 這個時候我們想到了接口，如果方法的參數(shù)是一個接口，而不是一個結構體，這樣對程序的限制就會放開了許多。因為任何實現(xiàn)該接口的結構體都可以作為該方法的接口參數(shù)，這樣就可以保證后面在添加其他同類功能的時候，只需實現(xiàn)這個接口就可以滿足需求了。

比如如下一個需求：

定義兩個手機品牌結構體華為，蘋果，并打印出各自品牌的名字。保證程序的擴展性，后面我們可能還要加入小米

import "fmt"
//手機統(tǒng)一接口
type Phone interface {
  PrintBrand()
}
?
type HuaweiPhone struct {
}
func (hw *HuaweiPhone) PrintBrand() {
  fmt.Printf("品牌名字：華為")
}
?
type Iphone struct {
}
func (ip *Iphone) PrintBrand() {
  fmt.Printf("品牌名字：蘋果")
}
//統(tǒng)一打印方法
func PrintBrand(phone Phone) {
  phone.PrintBrand()
}
func main() {
  hw := HuaweiPhone{}
  ip := Iphone{}
  PrintBrand(ip)
  PrintBrand(hw)
}

如上面代碼，我們定義了兩個手機品牌的結構體，我們想打印各個手機的品牌名字，需要調用統(tǒng)一打印方法就可以了，如果后面添加其他品牌的話，我們只需要實現(xiàn)Phone這個接口就可以，如下添加小米手機品牌：

type XiaomiPhone struct {
}
func (xm XiaomiPhone) PrintBrand() {
  fmt.Printf("品牌名字：小米")
}

以上代碼我們可以看到，通過接口也可以定義一些泛化的行為。

工廠+泛型來實現(xiàn)更通用的泛化編程

可是有時候，即便我們使用了接口，對程序的約束依然還是很強，因為一旦我們指明了具體的接口，就會要求我們必須使用特定的接口。而我們希望編寫更通用的代碼，要使代碼能夠應用于某種不具體的類型，而不是具體的一個接口或者結構體。這個要怎么辦呢？

比如，我們基于以上的需求繼續(xù)加需求

由于我們對接的品牌增大到20種，除了上面三種還有魅族、三星、諾基亞、中興。。。。等等

這個時候我們基于當前的代碼已經(jīng)不能滿足，那么我們想到了工廠設計模式，在工廠中用泛型來泛化所有的類型，我們通過傳入類型名字來打印出具體的品牌名。我們引入工廠模式繼續(xù)優(yōu)化我們的代碼，

如下：

var cache sync.Map
//工廠方法 可以傳入任意的類型
func PhoneFactory[T any]() (t *T) {
  target := reflect.TypeOf(t)
  v, ok := cache.Load(t)
  if ok {
    return v.(*T)
  }
  v = new(T)
  v, _ = cache.LoadOrStore(target, v)
  return v.(*T)
}
func main() {
  PrintBrand(PhoneFactory[Iphone]())
  PrintBrand(PhoneFactory[HuaweiPhone]())
  PrintBrand(PhoneFactory[XiaomiPhone]())
}

代碼中我們編寫了個工廠方法，泛型類型為 any, 接收任意的類型，在工廠中我們創(chuàng)建對象返回相應的類型并緩存類型對象防止重復創(chuàng)建。這樣我們后面再加其他類別的時候可以通過這個工廠方法來統(tǒng)一的創(chuàng)建，我們還可以通過反射在創(chuàng)建前后根據(jù)業(yè)務需要做一些操作。

泛型使用的最佳時機

泛型的加入，無疑增加了代碼的復雜度，那么我們使用泛型的最佳時機是什么時候呢？

Go 泛型主要設計者 Ian Lance Taylor 給出了簡要的泛型使用方針，當開發(fā)者發(fā)現(xiàn)自己多次編寫完全相同的代碼，而這些副本之間的唯一區(qū)別僅在于使用了不同類型，這時候便可以考慮使用類型參數(shù)。換句話說，即開發(fā)者應避免使用類型參數(shù)，直到發(fā)現(xiàn)自己要多次編寫完全相同的代碼。

關于功能設計的簡單建議

比如說上面的業(yè)務，其實我們開始設計的時候設計到接口層面就可以了，如果一開始就引入工廠方法，其實這算是過度設計，我們設計一個功能的原則是，抓住上下文，適度設計，因為一旦我們投入了過多的精力到靈活設計上，勢必會影響本應該完成的需求。同時，過多的功能會引入更多潛在的問題，而修復問題也會耗費我們的時間和精力。而且在當前這個敏捷開發(fā)的時代，更是如此。