接口的设计原则有很多. 今天我们来研究两种. 后面在陆续研究
1. 开闭原则
2. 依赖倒置原则
interface是Go语言的基础特性之一,可以理解为对一种类型的规范或者约束. 他跟java,c++不同,Go语言实现接口不需要显示说明实现了哪个接口,也没有继承或者子类或者implement关键字.
只是通过约定的形式,隐式的实现接口中的方法即可. 这样的好处
1. go的interface写起来更自由,无需显示的实现,只要实现了与interfece所包含的所有函数签名的相同的方法即可.
2. 让编码更灵活,易扩展.
如何理解go语言中的interface呢?
1. interface是方法声明的集合
3. 接口中所有方法均被实现
4. interface可以作为一种数据类型,实现了该接口的任何对象都可以给对应的接口类型变量赋值
特别说明两点
a. interface 可以被任意对象实现，一个类型/对象也可以实现多个 interface
b. 方法不能重载，如 eat(),eat(s string) 不能同时存在
那么作为interface数据类型，他存在的意义在哪呢？ 实际上是为了满足一些面向对象的编程思想。我们知道，软件设计的最高目标就是高内聚，低耦合。那么其中有一个设计原则叫开闭原则。什么是开闭原则
一. 开闭原则
在面向对象编程领域中，开闭原则规定“软件中的对象（类，模块，函数等等）应该对于扩展是开放的，但是对于修改是封闭的”，这意味着一个实体是允许在不改变它的源代码的前提下变更它的行为。
看重点: 对于扩展是开放的,对于修改是封闭的.
举个例子: 银行每天要办理不同的业务,存款,转账,取款等. 如果直接是实体来实现如下
package bank import "fmt" type Banker struct { } func (b *Banker) Save() { fmt.Println(存钱) } func (b *Banker) Transfer() { 转账Banker) Get() { 取钱) }
有个人要来存钱取钱转账了
package main import aaa/bank func main() { var b = bank.Banker{} b.Save() b.Get() b.Transfer() }
那么随着业务越来越多,越来越大. 我又要新增加一些业务,比如基金,股票. 然后越来越多,越来越大. 导致Banker这个模块越来越臃肿
我们使用开闭原则,使用interface将banker模块抽象出来. 然后根据这个抽象的模块,去实现save,get,transfer.....
" // 对银行的业务进行抽象 type Business interface { doBussiness() } 存钱业务 type SaveBussiness struct { } func (b *SaveBussiness) doBussiness() { fmt.Sprintf() } 取钱业务 type GetBussiness struct { } func (g *GetBussiness) doBussiness() { 转账业务 type TransferBusi struct { } func (t *TransferBusi) doBussiness() { ) }
然后我今天去了银行,我们封装一个银行,银行有各种各样的能力.
package main import ( " ) 这有一个银行,银行可以办理业务 func Bank(b bank.Business) { 办理业务: ,b.DoBussiness()) } func main() { 办理具体的业务 Bank(&bank.SaveBussiness{}) Bank(&bank.GetBussiness{}) Bank(&bank.TransferBusi{}) }
这样,当银行增加业务类型,比如股票的时候,只需要扩展业务接口就可以了,不会对原来的接口进行修改
接口的意义:
现在interface已经基本了解，那么接口的意义最终在哪里呢，想必现在你已经有了一个初步的认知，实际上接口的最大的意义就是实现多态的思想，
就是我们可以根据interface类型来设计API接口，那么这种API接口的适应能力不仅能适应当下所实现的全部模块，也适应未来实现的模块来进行调用。
调用未来可能就是接口的最大意义所在吧，这也是为什么架构师那么值钱，因为良好的架构师是可以针对interface设计一套框架，在未来许多年却依然适用。
二. 依赖倒置原则
1. 什么是依赖倒置原则
张三驾驶奔驰,张三驾驶宝马,张三驾驶丰田.
李四驾驶宝马,李四驾驶奔驰,李四驾驶丰田
package yldz import 奔驰车 type Benz struct { } func (b *Benz) run() string{ return 奔驰启动) }
// 宝马 type BM struct { }
func (b *BM) run() 宝马启动) }
//丰田 type FT struct { } func (t *FT) run() 丰田启动) }
//====驾车人,张三 type Zhangsan struct { } func (t *Zhangsan) DriverBenz(b *Benz) { 张三驾驶BM) { FT) {aaa/yldz func main() { z := yldz.Zhangsan{} z.DriverBenz(&yldz.Benz{}) z.DriverBM(&yldz.BM{}) z.DriverFT(&yldz.FT{}) }
我们来看上面的代码和图中每个模块之间的依赖关系，实际上并没有用到任何的interface接口层的代码，显然最后我们的两个业务 张三开奔驰,
李四开宝马，程序中也都实现了。但是这种设计的问题就在于，小规模没什么问题，但是一旦程序需要扩展，比如我现在要增加一个凯迪拉克汽车 或者 司机王五，
那么模块和模块的依赖关系将成指数级递增，想蜘蛛网一样越来越难维护和捋顺。
2. 面向抽象层依赖倒转
interface接口的设计，type Car interface { Run() } type Driver interface { 接口变量肚子里有一个指针,所以接口变量不需要使用指针. Driver(car Car) } type Benz struct { } func (b *Benz) Run() ) } 宝马车 type BM struct { } func (b *BM) Run() 丰田车 type FT struct { } func (t *FT) Run() ====张三 type Zhangsan struct { } func (t *Zhangsan) Driver(car Car) { 驾驶func main() { benz := yldz.Benz{} zs := yldz.Zhangsan{} zs.Driver(&benz) ft := yldz.FT{} zs.Driver(&ft) }
