这就会产生一种“过设计”的味道了。
要注意，接口的确可以实现解耦，但它也会引入“抽象”的副作用，或者说接口这种抽象也不是免费的，是有成本的，除了会造成运行效率的下降之外，也会影响代码的可读性。不过这里你就不要拿我之前讲解中的实战例子去对号入座了，那些例子更多是为了让你学习 Go 语法的便利而构建的。
在多数情况下，在真实的生产项目中，接口都能给应用设计带来好处。那么如果要用接口，我们应该怎么用呢？怎么借助接口来改善程序的设计，让系统实现我们常说的高内聚和低耦合呢？这就要从 Go 语言的“组合”的设计哲学说起。
二、一切皆组合
2.1 一切皆组合
Go 语言之父 Rob Pike 曾说过：如果 C++ 和 Java 是关于类型层次结构和类型分类的语言，那么 Go 则是关于组合的语言。如果把 Go 应用程序比作是一台机器的话，那么组合关注的就是如何将散落在各个包中的“零件”关联并组装到一起。组合是 Go 语言的重要设计哲学之一，而正交性则为组合哲学的落地提供了更为方便的条件。
正交（Orthogonality）是从几何学中借用的术语，说的是如果两条线以直角相交，那么这两条线就是正交的，比如我们在代数课程中经常用到的坐标轴就是这样。用向量术语说，这两条直线互不依赖，沿着某一条直线移动，你投影到另一条直线上的位置不变。
在计算机技术中，正交性用于表示某种不相依赖性或是解耦性。如果两个或更多事物中的一个发生变化，不会影响其他事物，那么这些事物就是正交的。比如，在设计良好的系统中，数据库代码与用户界面是正交的：你可以改动界面，而不影响数据库；更换数据库，而不用改动界面。 编程语言的语法元素间和语言特性也存在着正交的情况，并且通过将这些正交的特性组合起来，我们可以实现更为高级的特性。在语言设计层面，Go 语言就为广大 Gopher 提供了诸多正交的语法元素供后续组合使用，包括：
在这些正交语法元素当中，接口作为 Go 语言提供的具有天然正交性的语法元素，在 Go 程序的静态结构搭建与耦合设计中扮演着至关重要的角色。 而要想知道接口究竟扮演什么角色，我们就先要了解组合的方式。
构建 Go 应用程序的静态骨架结构有两种主要的组合方式，如下图所示：
我们看到，这两种组合方式分别为垂直组合和水平组合，那这两种组合的各自含义与应用范围是什么呢？下面我们分别看看这两种组合。
2.2 垂直组合
当我们通过垂直组合将一个个类型建立完毕后，就好比我们已经建立了整个应用程序骨架中的“器官”，那这些器官手、手臂等，那么这些“器官”之间又是通过关节连接在一起的。
在 Go 应用静态骨架中，什么元素经常扮演着“关节”的角色呢？我们先来看个例子，假设现在我们有一个任务，要编写一个函数，实现将一段数据写入磁盘的功能。通常我们都可以很容易地写出下面的函数：
func Save(f *os.File, data []byte) error
复制代码
我们看到,这个函数使用一个 *os.File 来表示数据写入的目的地,这个函数实现后可以工作得很好。但这里依旧存在一些问题,我们来看一下。
首先,这个函数很难测试。os.File 是一个封装了磁盘文件描述符(又称句柄)的结构体,只有通过打开或创建真实磁盘文件才能获得这个结构体的实例,这就意味着,如果我们要对 Save 这个函数进行单元测试,就必须使用真实的磁盘文件。测试过程中,通过 Save 函数写入文件后,我们还需要再次操作文件、读取刚刚写入的内容来判断写入内容是否正确,并且每次测试结束前都要对创建的临时文件进行清理,避免给后续的测试带去影响。
其次,Save 函数违背了接口分离原则。根据业界广泛推崇的 Robert Martin(Bob 大叔)的接口分离原则(ISP 原则,Interface Segregation Principle),也就是客户端不应该被迫依赖他们不使用的方法,我们会发现 os.File 不仅包含 Save 函数需要的与写数据相关的 Write 方法,还包含了其他与保存数据到文件操作不相关的方法。比如,你也可以看下 *os.File 包含的这些方法:
func (f *File) Chdir() error
func (f *File) Chmod(mode FileMode) error
func (f *File) Chown(uid, gid int) error
... ...
复制代码
这种让 Save 函数被迫依赖它所不使用的方法的设计违反了 ISP 原则。
最后,Save 函数对 os.File 的强依赖让它失去了扩展性。像 Save 这样的功能函数,它日后很大可能会增加向网络存储写入数据的功能需求。但如果到那时我们再来改变 Save 函数的函数签名(参数列表 + 返回值)的话,将影响到 Save 函数的所有调用者。
综合考虑这几种原因,我们发现 Save 函数所在的“器官”与 os.File 所在的“器官”之间采用了一种硬连接的方式,而以 os.File 这样的结构体作为“关节”让它连接的两个“器官”丧失了相互运动的自由度,让它与它连接的两个“器官”构成的联结体变得“僵直”。
那么,我们应该如何更换“关节”来改善 Save 的设计呢?我们来试试接口。新版的 Save 函数原型如下:
func Save(w io.Writer, data []byte) error
复制代码
可以看到,我们用 io.Writer 接口类型替换掉了 *os.File。这样一来,新版 Save 的设计就符合了接口分离原则,因为 io.Writer 仅包含一个 Write 方法,而且这个方法恰恰是 Save 唯一需要的方法。
另外,这里我们以 io.Writer 接口类型表示数据写入的目的地,既可以支持向磁盘写入,也可以支持向网络存储写入,并支持任何实现了 Write 方法的写入行为,这让 Save 函数的扩展性得到了质的提升。
还有一点,也是之前我们一直强调的,接口本质是契约,具有天然的降低耦合的作用。基于这点,我们对 Save 函数的测试也将变得十分容易,比如下面示例代码:
func TestSave(t *testing.T) {
b := make([]byte, 0, 128)
buf := bytes.NewBuffer(b)
data := []byte("hello, golang")
err := Save(buf, data)
if err != nil {
t.Errorf("want nil, actual %s", err.Error())
}
saved := buf.Bytes()
if !reflect.DeepEqual(saved, data) {
t.Errorf("want %s, actual %s", string(data), string(saved))
}
}
复制代码
在这段代码中,我们通过 bytes.NewBuffer 创建了一个 *bytes.Buffer 类型变量 buf,由于 bytes.Buffer 实现了 Write 方法,进而实现了 io.Writer 接口,我们可以合法地将变量 buf 传递给 Save 函数。之后我们可以从 buf 中取出 Save 函数写入的数据内容与预期的数据做比对,就可以达到对 Save 函数进行单元测试的目的了。在整个测试过程中,我们不需要创建任何磁盘文件或建立任何网络连接。
看到这里,你应该感受到了,用接口作为“关节(连接点)”的好处很多!像上面图中展示的那样,接口可以将各个类型水平组合(连接)在一起。通过接口的编织,整个应用程序不再是一个个孤立的“器官”,而是一幅完整的、有灵活性和扩展性的静态骨架结构。
现在，我们已经确定了接口承担了应用骨架的“关节”角色，接下来我们来看看接口是如何演好这一角色的。
三、接口应用的几种模式
