go 学习笔记之万万没想到宠物店竟然催生出面向接口编程?

到底是要猫还是要狗

在上篇文章中,我们编撰了一则简短的小故事用于讲解了什么是面向对象的继承特性以及 Go 语言是如何实现这种继承语义的,这一节我们将继续探讨新的场景,希望能顺便讲解面向对象的接口概念.

为了照顾到没有看过上一节文章的读取,这里再简述一下上节文章关于买宠物的故事,如需详细了解,请自行翻阅历史文章进行查看.

A: 猫是一种宠物,淘气可爱会卖萌,看家本领抓老鼠,偶尔还会喵喵喵.
B: 狗是一种宠物,忠实听话能看家,嗅觉灵敏会破案,一言不合汪汪汪.
C: 我想要买一个宠物,文能卖萌,武可退敌,明个一早给我送来吧!

于是,第二天,A和B各自带着自己的宠物来拜见C,并附上各自的理由,说的头头是道,C总觉得有些哪里不对,可一时间又无言反驳,只能悻悻收下了猫和狗,白白多花了一份钱!

这则故事很简单,但同时也暴露出一个问题,那就是在这场交易中,卖家实际上亏了,明明只是想买一个宠物,结果却买了两个!

当然,在上篇文中最后也给出了解决方案,那就是将猫和狗进行抽象封装,共性的部分提取成宠物,个性的部分才是猫和狗.

如此一来,顾客买宠物时要么买的是猫,要么面对是狗,具体买的是什么宠物是由顾客自己根据各自宠物的个性决定的,一定程度上解决了交易不公平的问题.

让我们再简单回忆一下继承的实现过程,回忆的过程中不妨思考一下继承有没有没能解决的问题?

• 宠物默认自带能文能武技能

type Pet struct {

}

func (p *Pet) Skill() {
    fmt.Println("能文能武的宠物")
}

• 猫是宠物,还是能抓老鼠的宠物.

type Cat struct {
    p *Pet
}

func (c *Cat) Catch() {
    fmt.Println("老鼠天敌喵喵喵")
}

• 狗是宠物,还是能认路导航的宠物.

type Dog struct {
    p *Pet
}

func (d *Dog) Navigate() {
    fmt.Println("自带导航汪汪汪")
}

某一天,C要能文能武的宠物,最好还可以顺便抓个老鼠,于是C选择了喵喵喵!

func TestExtendInstance(t *testing.T) {
    p := new(Pet)
    c := new(Cat)
    c.p = p

    // 老鼠天敌喵喵喵
    c.Catch()
    // 能文能武的宠物
    c.p.Skill()
}

过了一阵子,C觉得猫除了抓老鼠别的什么都不会,别人遛狗,我遛猫?

于是,想要一种能自带导航功能的宠物,毫无疑问的是,选择了狗.

func TestExtendInstance(t *testing.T) {
    p := new(Pet)
    d := new(Dog)
    d.p = p

    // 自带导航汪汪汪
    d.Navigate()
    // 能文能武的宠物
    d.p.Skill()
}

上述示例,简而言之就是通过组合的方式实现了面向对象中的继承特性,解决了猫和狗除了是宠物还是自己的问题.

猫狗随便是宠物就行

面对猫和狗两种宠物,顾客犯了选择困难症,于是第一次全盘照收买下了两种宠物,吃了一次哑巴亏.

后来在市场监督的介入下,利用面向对象的继承特性,用 Go 语言实现了猫和狗的个性化与宠物的共性化,从此像C一样的顾客再也不会面临选择困难症,每一次都要根据独特的需求,最终选择某一种宠物,要么是猫,要么是狗.

不知过了多久,这种相安无事的场景最终被一群急性子的顾客所打破,这一天宠物市场一大早就来一大批人,一上来就吵吵嚷嚷说快给我们一批宠物,我们要作为抽奖活动的奖品,一定要快一点!

谁知道销售人员不紧不慢地说: "别着急,我们这里的宠物有很多种,有猫,有狗,有兔子,有金鱼,有乌龟,有蜗牛..."

"别整那些虚头巴脑的,我只要宠物,赶紧给我宠物就行,别尽扯没用的",顾客吵吵说.

果然是一群急性子的顾客,还没等销售人员介绍完各个宠物的差异性亮点直接被打断了.

宠物市场吵吵闹闹引来了市场监督人员的注意,顾客和商家均向官方诉苦,期望能给出一个解决办法!

市场监督人员心想: 商家和顾客原本和谐相处的,今天怎么会吵闹起来?

仔细听了事情来龙去脉,双方都没有过错,看来还真的是市场赶不上实际需求的变化,真得尽快研究新的解决办法才行啊!

"冷静一下,你们的意见我们这边已经知道了,这样吧,给我们三天的时间,我们一定会想出一个万全之策,到时候再公布新的交易规则,现在我宣布暂时关闭交易,省的再惹出不必要的争端!"

原本吵吵嚷嚷的市场顿时冷却了不少,毕竟谁也不敢违抗市场老大的命令,众人只得悻悻而去,期待三天后的重新开市.

视角切换到市场监督大会上,主席首先开始发言:"各位,现在市场面临的问题想必大家都有所耳闻吧,我们已经郑重承诺,三天后必须给市场一个答复,时间紧,任务重,大家要集思广益,一起解决这个难题!"

"现在的顾客到底是怎么了,连自己到底想要什么都搞不清楚,还急冲冲地跑来买宠物,自己都不知道要买啥,鬼才知道呢!",资历老练的继承经理抱怨道.

"经理说得对,他们自己都不知道到底想要啥宠物,怎么能埋怨商家太罗里吧嗦呢?人家那么卖力介绍宠物的特点,不也是帮助顾客更好的选择嘛!",发言的是继承经理的小弟.

"..."

"咳咳,我理解大家的心情,继承项目组确实在解决宠物问题上立下了很大功劳,大家为他们抱不平也是情理之中的事情,过去的就让他过去吧!当务之急,还是要解决现实问题!",主席首先安抚前几位激动情绪,又挑出重点提醒在场的各位回归到主题的讨论上,不要再揪住过去的功劳簿.

"我觉得,心急顾客的真正需求只是想要一种宠物,而不再关注宠物的种类,管他是猫是狗,只要是宠物就行.所以我们应该提供一种新的机制,对外宣传时只说这是宠物,至于这种宠物到底是猫还是狗,都可以!"

"猫和狗明明已经是宠物了啊,难道不可以直接卖给顾客吗?为啥还要提供新机制?"

"猫和狗虽然是宠物,但对于用户来说,这种宠物有点浪费了,用户实际使用到可能只是宠物的功能,并不会用到也不能用到具体宠物的功能,所以对用户来说,这就是一种浪费."

"哦哦,明白了,这就像是顾客需要的宠物是能卖萌的,是要送给女朋友作为礼物的,并不关心这个宠物能不能抓老鼠.所以对于抓老鼠的技能就是没用的,而买家却要为抓老鼠的技能额外买单,这对于买家来说并不公平!"

经过一番激烈的讨论,大家基本上达成一致,先前存在的继承模型确实有些不足,不能适应快速变化的市场,过于强调差异性而非共性.

这样就导致无法满足急性子顾客批量购买的需求,所以需要提供类似于继承那种抽象的概念来表达某种约定,只要满足这种约定的动物就是宠,不管是猫还是狗,哪怕是玩具也行!

让继承变得更加抽象

透过现象看本质,从纷繁冗杂的事务中抽象出精简的模型是各个编程语言都必不可少的一个环节,Go 语言当然也不例外.

面向对象编程中的继承概念表达是一种上下级的抽象关系,也就是说某一个封装对象是从属于特定上级的封装对象,默认拥有该上级的行为方法,这里的上级概念就是父类就是对所有子类共性的抽象实现.

当研究的问题就是具体的子类实现时,此时使用继承的概念,语义上比较清晰,子类只需要关注自己的特性,共性部分由父类去完成,这种思路也是非常自然的,猫是猫的同时也是一种宠物.

但是当我们研究的问题不再关注具体的子类实现而是着眼于父类的共性时,此时如果再提供具体的子类实现当然也能用,但是杀鸡焉用牛刀?

明明我仅仅需要一滴水,你却给了我整个海洋!

本来,真正需要的可能只是父类的某一个方法,你却提供给我一个具体的子类实现,这个子类不但拥有目标方法还有很多的其他方法.

既然有这么多的附加价值,你说浪费不浪费,销售时可不得涨价吗,这样不相当于捆绑销售了嘛!

所以,我们需要对继承的概念进一步抽象,使这种抽象达到一种极致状态以至于只存在非常少量的行为方法,凡是继承自这种极致抽象的子类都是它的子民.

为了之后讨论方便,业界将这种抽象到极致的继承关系称之为接口,虽然看似只是称呼的改变,但实际上思维方式上已经发生了翻天覆地的变化.

继承的概念是描述子类和父类的关系,子类继承自父类,关注点在子类,共性部分完全由父类实现,子类自然拥有这些行为能力.

而接口的概念衍生于继承,只不过是这种抽象程度已经达到了一种不能再抽象的地步,所有子类都要有一个最终的父类,这个父类拥有最公共性的行为方法,所以这种极致的抽象也就无法体现出子类的共性行为的具体表现.此时这种极致的抽象没有太大的意义,是一种非常非常宽泛的概念,等于什么都没说,所以也适合绝大部分封装对象.

所以,干脆取消了极致抽象中对于行为共性的实现,转而仅仅定义共性的行为,具体这种行为到底如何表现,完全由具体子类自行决定.

这样做有两个显而易见的好处,一是解决了太宽泛概念等于没说的尴尬,同时保留了对共性行为的描述.二是将控制权转移到具体的子类实现,实现了体制内的个性化!

所以这种专业名词的转变背后是思维方式的转变,而接口更是很好地描述了这种转变的语义.

回忆一下生活总随处可见的 USB 数据线,对于计算机来说,对外暴露的是 USB 插口,行为描述是只要插入就能连接到电脑,能够同电脑进行沟通交流,这种交流可能是传递数据,也可能是连接电源等等不同的行为表现.

基于接口设计,USB 数据线提供了访问电脑的能力,一端连着电脑,另一端连着手机,双方进行数据交换.
有线鼠标的数据线也提供了访问电脑的能力,实现鼠标的左击还是又击都能反馈到电脑.

诸如此类的案例不胜枚举,生活中不缺少计算机哲学,缺少的只是我们的思考.

所以,如果让我来给这种机制进行命名的话,我可能会将其称呼为插口,意思是只要能适配指定的插口,那么就说满足插口要求,对外暴露的抽象概念是插口,真正的实现可能是数据线或者工具等.

当然,这只是我的一厢情愿,因为面向对象中这种机制叫做接口,满足接口的规范叫做实现了接口.

接口这种概念显得比较专业,提出这个概念的人估计也是厉害人物,基本上所有的面向对象语言中都采用了接口的概念,即使不是面向对象语言但支持面向对象编程风格的 Go 语言也采用了接口概念.

由此可见,接口的概念应该是通俗易懂,可移值性比较强的,获得了相当高的认可度.

除了面向对象编程风格外,与接口相关的编程风格中还有一种叫做面向接口编程,这个会在以后的文章中继续分享这封面的内容.

个人理解封装和继承的概念,讲的就是面向对象编程,关注点在于具体的对象以及对象之间的层次关系.

而接口的出现则是另外一种维度的思考,当关注点不再是具体的子类而是抽象的父类,这种情况下则根据实际情况抽象出了接口的概念,由此看出,面向对象编程中高内聚部分说的是封装和继承,低耦合则是接口和多态.

所以面向接口编程在应用而生,由此可见,不同的应用场景关注点不同,面向对象和面向接口也并不是互斥关系,是互补关系.

在未来的某种需求继续发生改变时,可能还会产生新的概念,进而提出新的一套理论,到时候是面向需求编程还是面向思维编程亦或是面向搜索编程,那就就不得而知了.

聪明的读者,你们有什么看法呢?

如何设计又怎么实现

市场监督大会散会后,继承小组接受了设计接口的任务挑战.大会之所以推举继承小组领头,是因为与会人员一致认为继承小组在处理抽象概念上十分擅长,相信设计出接口这种机制也是可以的.

继承小组深感此次任务责任重大,任重而道远,一定要设计出接口概念才能不辜负参会人员的认可和领导的厚爱.

于是,继承小组内部在一起开了个会,会上大家畅所欲言谈谈自己的看法.

小王: "我觉得这种接口的概念是抽象的终极状态,我们可能没办法一下子到达终点,但是按照现有的理论应该可以逐步逼近终点."
小李: "我也是有类似的感觉,抽象到什么程度才是终点呢?拿什么判定这个抽象程度呢?猫和狗到宠物的过程是一种抽象过程,我们先前也是基于此过程提出了继承的概念,解决了重复定义的问题.现在应该沿着这种思路继续抽象,直到小王说的那种接口概念."
小张: "从猫和狗抽象到宠物,是封装对象的演进过程,顾客需要的不是具体的猫和狗,而是宠物.但是这个宠物直觉上感觉和原来继承中实现的宠物还是有点不一样啊?"
小王: "我也有同感,这次的宠物必须具备某种能力,只要是满足这种能力的,管他是猫还是狗或者是别的什么蜥蜴蟑螂的都是顾客眼中的宠物.所以这种宠物更加单一化,并不在乎有没有其他能力."

...

大家你一言我一语的讨论了好长时间,最终在项目经理的引导整理下有了有了初步的思路.

• 接口是一种抽象,这种抽象可能并不关注父类本身的全部能力,只在于关注的能力.
• 普通的抽象父类既有行为的约束还顺便实现了该行为,但抽象到接口这种程度时是否实现并不在乎,但必须要有行为的约束.
• 接口本身的语义是一种行为约束,满足这种约束行为的具体对象可能会有很多,同时这些具体对象可能也满足其他接口约束.
• 接口约束变化时,满足接口约束的具体子类到底要不要随之变化?如果需要的话,有道理,如果不需要的话,也有道理.

"等一下,我有疑问?你怎么一会说需要,一会又说不需要,这不自相矛盾了吗?",大家几乎不约而同举手示意经理.似乎早就料到这帮小子搞不懂其中缘由,经理故弄玄虚地回应说:"嗯嗯,我就知道你们会有疑惑,下面容我谈一下我的看法,你们听听看.”

如果站在接口的定义者角度上看问题,一旦发布了接口规范,子类肯定会屁颠屁颠满足接口约束,于是对外暴露时都是接口那一套理论,忽略了自己的特色.

统一了接口规范这种情况对于接口设计者最为方便,所有的控制权全部掌握在自己手中,一道命令即可号令群雄,莫敢不从,如若不从,轻则千夫所指,重则驱逐出境!

对于接口设计者来说,这些实现了接口的对象并没有什么不同,地球离了谁照样自转,随时随地想换就换.

但是对于接口的实现类来说,只要一收到天子诏令,立马无条件停下手上的活,熬夜加班也要满足新的接口规范,敢怒不敢言,除非是不想混了,哪怕怠慢了一步也会引发巨大的动荡!

所以说接口更改时,具体的实现类必须要随之改变以实现新的接口规范约束.

如果站在接口的使用者角度上看问题,是否实现接口应该是我的地盘我做主,是自主决定的事情,管你接口是否更改,老子爱实现就实现,不乐意实现就不实现!你奈我何?我的王国我当家,尊你敬你你才是国王,把我们惹恼了,所谓的联合王国到时候只剩你这么一个孤家寡人去吧!

所以说接口更改时,具体的实现类不需要随之更改,想不想满足新的接口规范完全在于自己,并不是强迫的,不必立即实现新的接口规范.

真的是公说公有理婆说婆有理,既然如此,那么问题来了,Go 语言选择是哪一种?其他主流的编程语言又是选择哪一种的呢?

先说其他主流的编程语言,这类编程语言大多是站在接口设计者角度出发,控制欲特别强,一言不合就报错,接口更新了实现类必须同步更新,违令者杀无赦!

这样有优点也有缺点,优点是皇帝一声令下,天下臣民莫敢不从,屡教不敢者,千夫所指,王国崩溃也不是没有可能!
正是这种优点,换另外一种角度看就是缺点了,俗话说天高皇帝远,圣旨虽下但还没传达到边境要塞,那边监察御史就上奏你一本,说你怠政目无尊上,引发帝国动荡,罪大恶极,理应凌迟处死!

你说冤不冤,不管是朝令夕改还是焕然一新的改革,凡是曾经实现过接口的类都要实时更新,否则后果不堪设想.

真的是成也萧何败萧何,控制欲太强有利有弊.

所以,Go 与众不同,选择了另一种思路来解决问题,放弃中央集权转向分封制,将权力下放给地方.

名义上还是由国王制定统一标准,由地方负责自主实施,具体如何实现标准完全是诸侯国自己的事情,万一哪天国王需要使用统一标准时,实现了该标准的诸侯王国都可以无障碍使用.

即使以后接口规范有变,旧的接口不再适合新时代要求,国王只需要制定了一套新的标准,昭告天下后,当诏令传到地方时,地方可以根据新的规范更新自己的实现类,万一消息闭塞或者不愿意立即更新,也没关系,王国不会崩溃,只不过需要使用新规范时,没有实现接口的地方自然是不能使用的.

因此,不论是集中制还是民主制,接口的规范都是自顶向下实施的,不同之处在于底下的人因各种原因没有实现新的接口规范时,集中制会直接崩溃而民主制依旧正常运行,仅此而已.

下面就演示一下两种思路的实现方式.

• java 等传统的面向对象语言

卖家首先定义到底什么是宠物这种接口.

public interface Pet {
    void actingCute();
}

喵喵喵,人家能卖萌,就是宠物嘛,为啥还非得证明一下啊!

public static class Cat implements Pet {
    @Override
    public void actingCute() {
        System.out.println("喵星人喵喵喵来卖萌");
    }
}

这里说的证明一下猫是宠物,指的是必须使用关键字 implements 声明实现了宠物的接口,颁发了合格证才算是宠物,否则就不是.

汪星人说,这年头自带卖萌天赋的猫咪都要通过专业认证才算是宠物,我也乖乖去认证宠物吧!

public static class Dog implements Pet {
    @Override
    public void actingCute() {
        System.out.println("汪星人汪汪汪来卖萌");
    }
}

第二天,市场上又来了一群急性子的买家,一上来就要买宠物,管他是猫还是狗,并不在乎,只要是宠物就行.

public static void main(String[] args) {
    Pet p;
    
    p = new Cat();

    // 喵星人喵喵喵来卖萌
    p.actingCute();

    p = new Dog();

    // 汪星人汪汪汪来卖萌
    p.actingCute();
}

终于送走了这批顾客,卖家也舒了一口气,默默念叨着,市场监督那帮人真牛逼,竟然设计出接口的方案,只要是宠物,别管是猫还是狗,随便给一个都行,给这帮人点个赞!

• go 等非传统非面向对象语言

首先定义接口规范,宠物一定要能卖萌,不然怎么讨得女神欢心?

type Pet interface {
    ActingCute()
}

喵喵喵说我会卖萌啊,那我就是宠物啦!

type Cat struct {

}

func (c *Cat) ActingCute() {
    fmt.Println("喵星人喵喵喵来卖萌")
}

汪汪汪说我也会卖萌,我也要给女神当宠物!

type Dog struct {

}

func (d *Dog) ActingCute() {
    fmt.Println("汪星人汪汪汪来卖萌")
}

既然你们都会卖萌,对于直男来说这就够了,随便拿一个就行了,快点准备送礼物啦!

func SendGift(p Pet) {
    p.ActingCute()
}

于是乎,既然买家并不在乎到底是猫还是狗,那就卖给他一个猫好了,于是小伙子打包了宠物准备送给女神.

func TestActingCute(t *testing.T) {
    var p Pet
    p = new(Cat)

    // 喵星人喵喵喵来卖萌
    SendGift(p)
}

第二天,女神打来电话说,你不知道对猫毛过敏的吗,送的啥破礼物!哼!

可怜的小伙子跑去宠物店找卖家算账,气冲冲地质问卖家,卖家一脸毫不在意的样子,笑嘻嘻的说,小伙子想不想将功补过啊,这一次保准你能获得女神青睐.

只见,卖家这一次找来了一条宠物狗,打打包还放到原来的包装盒递给你小伙子.

func TestActingCute(t *testing.T) {
    var p Pet
    p = new(Dog)

    // 汪星人汪汪汪来卖萌
    SendGift(p)
}

我擦,还是原来的配方,有点担心,一样的包装这一次真的能讨得女神欢心,原谅自己吗?

亲爱的读者,你们说呢,同样的配方不一样的味道,女神会原谅自己吗?

同一个问题思路不同

不论是站在设计者角度上解决抽象问题还是站在使用者角度思考,两者的解决方案没有高低优劣之分,选用好恰当的应用场景就是最好的解决方案.

只不过这种选择往往不是开发者能左右的事情,因为这种底层的语言级别框架设计属于缔造者的工作,他们一旦觉得了一种模式,语言使用者很难改变,我们唯一能做的就是理解并使用罢了!

当站在接口设计者角度上时,接口的定义和具体实现类的关系就好比是集中制,皇帝一声令下,不管身处何处,天下臣民皆惟命是从,如有懒政懈怠者,千夫所指,立马崩溃.

当站在接口实现者角度上时,此时接口的设计者和具体实现者的关系是松耦合的,犹如分封制,国王一声令下,诸侯国可以听从差遣也可以抗旨不遵,对于整个王国而言并不会造成颠覆性混乱,诸侯国和国王更像是一种契约精神而不是隶属服从关系.

Go 语言中的接口采用的就是后一种松耦合的关系,接口设计者和接口实现者是松耦合的,实现的关系也是隐式的,这也是另一种理论"鸭子模型"的体现.

好了,本文主要介绍了为什么要有接口设计的需求以及接口设计是怎么思考的,并简单介绍了 Go 是如何实现这种模型的.

下一节我们将真正开始介绍 Go 语言关于接口的设计,顺便讲解面向对象最后一个知识点---多态.

如果本文对你理解面向对象有所帮助,欢迎你的的转发分享,如果文章有描述不当之处,希望你能留言告诉我,谢谢你的阅读.