。

今天#xff0c;我们继续讲一个跟“接口”相知识点:基于接口而非实现编程。

这个原则非常重要,是一种非常有效的提高代码质量的手段,在平时的开发中特别经常被用到。

为了让你…在上一节课中、我们讲了接口和抽象类以及各种编程语言是如何支持、实现这两个语法概念的。

今天我们继续讲一个跟“接口”相知识点:基于接口而非实现编程。

这个原则非常重要,是一种非常有效的提高代码质量的手段,在平时的开发中特别经常被用到。

为了让你理解透彻,并真正掌握这条原则如何应用,今天我会结合一个有关图片存储的实战案例来讲解。

除此之外这条原则还很被过度应用,比如为每一个实现类都定义对应的接口。

针对这类问题,在今天的讲解中,我也会告诉你如何来做权衡,怎样恰到好处用这条原则。

话不多说让我们正式开始今天的学习吧如何解读原则中的“接口”二字基于接口而非实现编程这条原则的英文描述是:

Program

implementation。

我们理解这条原则的时候,千万要一开始就与具体的编程语言挂钩,局限在编程语言的接口”语法中(比如Java中的interface接口语法)

。

这条原则最早出现于1994年GoF的《设计模式》这本书它先于很多编程语言而诞生比如Java语言是一条比较抽象、泛化的设计思想。

实际上,理解这条原则的关键就是理解其中的“接口”两个字。

还记得我们上一节课讲的“接口”的定义吗从本质上来看,“接口”就是一组“协议”或者约定”,是功能提供者提供给使用者的一个“功能列表”。

“接口”在不同的应用场景下会有不同的解读,比如服务端与客户端之间的“接口”类库提供的“接口”甚至是一组通信的协议都可以叫作“接口”。

刚刚对“接口”的理解都比较偏上层、偏抽象与实际的写代码离得有点远。

如果落实到具体的编码,

“基于接口而非实现编程”这条原则中的“接口”,可以理解为编程语言中的接口或者抽象类。

前面我们提到,这条原则能非常有效地提高代码质量,之所以这么说,那是因为,应用这条原则,可以将接口和实现相分离,封装不稳定的实现,暴露稳定的接口。

上游系统面向接口而非实现编程,不依赖不稳定的实现细节,这样当实现发生变化的时候,上游系统的代码基本上不需要做改动以此来降低耦合性提高扩展性。

实际上,

基于接口而非实现编程”这条原则的另一个表述方式,是“基于抽象而非实现编程”。

后者的表述方式其实更能体现这条原则的设计初衷。

在软件开发中,最大的挑战之一就是需求的不断变化这也是考验代码设计好坏的一个标准。

越抽象、越顶层、越脱离具体某一实现的设计,越能提高代码的灵活性,越能应对未来的需求变化。

好的代码设计,不仅能应对当下的需求,而且在将来需求发生变化的时候,仍然能够在不破坏原有代码设计的情况下灵活应对。

而抽象就是提高代码扩展性、灵活性、可维护性最有效的手段之一。

如何将这条原则应用到实战中?对于这条原则我们结合一个具体的实战案例来进一步讲解一下。

假设我们的系统中有很多涉及图片处理和存储的业务逻辑。

图片经过处理之后被上传到阿里云上。

为了代码复用,我们封装了图片存储相关的代码逻辑提供了一个统一的AliyunimageStore类供整个系统来使用。

具体的代码实现如下所示public

class

createBucketIfNotExisting(String

bucketName)

{...根据accesskey/secrectkey等生成access

token}public

{//...上传图片到阿里云...//...返回图片存储在阿里云上的地址(url)

...}public

ai_images_bucket;//...省略其他无关代码...public

void

//处理图片,并封装为Image对象AliyunImageStore

imageStore

AliyunImageStore(/*省略参数*/);imageStore.createBucketIfNotExisting(BUCKET_NAME);String

accessToken

imageStore.generateAccessToken();imagestore.uploadToAliyun(image,

BUCKET_NAME,

token上传图片到场定的bucket中。

代码实现非常简单类中的几个方法定义得都很干净用起来也很清晰乍看起来没有太大问题完全能满足我们将图共存储在阿里云的业务需求。

不过软件开发中唯一不变的就是变化。

过了一段时间后我们自建了私有云不再将图片存储到网里云了而是将图片存储到自建私有我上为了满足这样一个需求的变化我们该如何修改代码呢我们需要重新设计实现一个存储图片到私有云的PrivatelmageStore类并用它替换掉项目中所有的AliyunimageStore类对象。

这样的修改听起来并不复杂,只是简单替换而已,对整个代码的改动并不大。

不过,我们经常说,“细节是魔鬼”。

这句话在软件开发中特别适用。

实际上、刚刚的设计实现方式就隐藏了很多容易出问题的“魔鬼细节”我们一块来看看都有哪些。

新的PrivatelmageStore类需要设计实现哪些方法,才能在尽量最小化代码修改的情况下,替换掉AliyunimageStore类呢?这就要求我们必续将AliyunlmageStore类中所定义的所有publi还方法,在PrivatelmageStore类中都逐一定义并重新实现一遍。

而这样做就会存在一些间聽我总结了下面两点。

着先,AliyuntmageStore类中有些函数命名暴露了实现细节,比如,

uploadToAliyun(和downloadFromAliyun0,如果开发这个功能的同事没有接口意识、抽象思维,那这种暴露实现细节的命名方式就不足为奇了,毕竟最初我们只考虑将图片存储在阿里云上。

而我们把这种包含aliyun字眼的方法,照抄到PrivatelmageStore类中,显然是不合适的。

如果我们在新类中重新命名uploadToAliyun)downloadFromAliyun0这些方法那就意味着我们要修改项目中所有使用到这两个方法的代码代码修改量可能就会很大。

其次、将图片存储到阿里云的流程,跟存储到私有云的流程,可能并不是完全一致的。

比如,阿里云的图片上传和下载的过程中,需要生产access

token,而私有云不需要access

AliyunlmageStore中定义的generateAccessToken(方法不能照抄到PrivatelmageStore中另一方面我们在使用AliyunlmageStore上传、下载图片的时候代码中用到了generateAccessToken0方法如果要改为私有云的上传下载流程这些代码都需要做调整。

那这两个问题该如何解决呢解决这个问题的根本方法就是在编写代码的时候要遵从“基于接口而非实现编程”的原则具体来讲我们需要做到下面这3点。

1.函数的命名不能暴露任何实现细节。

比如,前面提到的uploadToAliyun(就不符合要求,应该改为去掉aliyun这样的字眼,改为更加抽象的命名方式比如upload()。

2,封装具体的实现细节。

比如,跟阿里云相关的特殊上传(或下载)流程不应该暴露给调用者。

我们对上传(或下载)流程进行封装对外提供一个包裹所有上传或下载细节的方法给调用者使用。

3.

为实现类定义抽象的接口。

具体的实现类都依赖统一的接口定义遵从一致的上传功能协议。

使用者依赖接口而不是具体的实现类来编程。

我们按照这个思路把代码重构一下。

重构后的代码如下所示public

interface

{createBucketIfNotExisting(bucketName);String

accessToken

generateAccessToken();//...上传图片到阿里云...//返回图片在阿里云上的地址(url)...}public

Image

createBucketIfNotExisting(String

bucketName)

...创建bucket.....失败会抛出异常..}private

String

根据accesskey/secrectkey等生成access

token}

bucketName){createBucketIfNotExisting(bucketName);//

...上传图片到私有云...//…..返回图片的url...}public

Image

createBucketIfNotExisting(String

bucketName)

ai_images_bucket;//……省略其他无关代码…..public

void

image……//处理图片、并封装为Image对象Imagestore

imagestore

PrivateImagestore(…)imagestore.upload(image,

BUCKET_NANE);}

}除此之外,很多人在定义接口的时候,希望通过实现类来反推接口的定义。

先把实现类写好,然后看实现类中有哪些方法,照抄到接口定义中。

如果按照这种思考方式,就有可能导致接口定义不够抽象,依赖具体实现。

这样的接口设计就没有意义了。

不过,如果你觉得这种思考方式更加顺畅,那也没问题,只是将实现类的方法搬移到接口定义中的时候,要有选择性的搬移,不要将跟具体实现相关的方法搬移到接口中,比如AliyunlmageStore中的generateAccessToken0方法。

总结一下,我们在做软件开发的时候,一定要有抽象意识、封装意识、接口意识。

在定义接口的时候,不要暴露任何实现细节。

接口的定义只表明做什么,而不是怎么做。

而且,在设计接口的时候,我们要多思考一下,这样的接口设计是否足够通用,是否能够做到在替换具体的接口实现的时候,不需要任何接口定义的改动。

是否需要为每个类定义接口看了刚刚的讲解,你可能会有这样的疑问:为了满足这条原则,我是不是需要给每个实现类都定义对应的接口呢?在开发的时候,是不是任何代码都要只依赖接口完全不依赖实现编程呢做任何事情都要讲求一个“度”,过度使用这条原则,非得给每个类都定义接口,接口满天飞,也会导致不必要的开发负担。

至于什么时候该为某个类定义接口实现基于接口的编程,什么时候不需要定义接口直接使用实现类编程我们做权衡的根本依据还是要回归到设计原则诞生的初衷上来。

只要搞清楚了这条原则是为了解决什么样的问题而产生的,你就会发现,很多之前模棱两可的问题,都会变得豁然开朗。

前面我们也提到,这条原则的设计初衷是,将接口和实现相分离,封装不稳定的实现,暴露稳定的接口。

上游系统面向接口而非实现编程,不依赖不稳定的实现细节,这样当实现发生变化的时候,上游系统的代码基本上不需要做改动,以此来降低代码间的耦合性,提高代码的扩展性。

从这个设计初衷上来看,如果在我们的业务场景中,某个功能只有一种实现方式,未来也不可能被其他实现方式替换,那我们就没有必要为其设计接口也没有必要基于接口编程直接使用实现类就可以了。

除此之外,越是不稳定的系统,我们越是要在代码的扩展性、维护性上下功夫。

相反,如果某个系统特别稳定,在开发完之后,基本上不需要做维护,那我们就没有必要为其扩展性,投入不必要的开发时间。

重点回顾今天的内容到此就讲完了。

我们来一块总结回顾一下你需要掌握的重点内容。

1.“基于接口而非实现编程”,这条原则的另一个表述方式,是“基于抽象而非实现编程”。

后者的表述方式其实更能体现这条原则的设计初衷。

我们在做软件开发的时候,一定要有抽象意识、封装意识、接口意识。

越抽象、越顶层、越脱离具体某一实现的设计,越能提高代码的灵活性、扩展性、可维护性。

2.我们在定义接口的时候,一方面,命名要足够通用,不能包含跟具体实现相关的字眼另一方面,与特定实现有关的方法不要定义在接口中。

3.“基于接口而非实现编程”这条原则不仅仅可以指导非常细节的编程开发还能指导更加上层的架构设计、系统设计等。

比如服务端与客户端之间的“接口”设计、类库的“接口”设计。

课堂讨论在今天举的代码例子中,尽管我们通过接口来隔离了两个具体的实现。

但是,在项目中很多地方,我们都是通过下面第8行的方式来使用接口的。

这就会产生一个问题那就是如果我们要替换图片存储方式还是需要修改很多类似第8行那样的代码。

这样的设计还是不够完美对此你有更好的实现思路吗?//

class

ai_images_bucket;//...省略其他无关代码...public

void

...;//处理图片并封装为Image对象ImageStore

imageStore

PrivateImageStore(/*省略构造函数*/);imagestore.upload(image,

BUCKET_NAME);}