只有一个类时,要不要出接口

如果一个接口后面,只有一个实现它的类,那么这个接口,还真正有必要吗?

我觉得百分之九十的人提出这个问题时的情形是应该这样的:他没有用接口的习惯,在能少则少的指导思想下,只要是只有一个类,他绝对不用接口。突然有一天,他看到他的一个同事,在写具体的类之前,先把接口写好了并且写了相应的文档解释这个接口应该提供的服务,可之后只实现了一个类。他就问了,这个接口有必要吗?这个问题暂且先放下不说,看完另外一种情形,在加讨论。

试想我们有一段写好的代码,用了接口,接口后面,有两个具体实现此接口的类,突然有一天,我们发现,其中有一个类,以后不会再被用了,于是乎就把这个类给删了,这时只剩下了一个类,那么敢问,是不是把接口也给删了呢?

以上两个问题,其实都是在对同一件事发问,但是出发点不一样,但我觉得这两个问题结合在一起回答,会使答案更加清晰。

先分析第一种情况,有意思的是,他那个同事为什么在实现类之前,先把接口给定义了? 先实话告诉你,我就是那个喜欢用接口的人。所以我就都交代了先。我之所以先写了个接口,倒不是因为,一下就想到了,接口后面会有多少具体实现的类,而是为了想先搞定依赖于此服务的另一模块。打个比方吧,我正在写的这个模块需要一个缓存服务,但缓存不是它的核心业务,所以说它根本不关心缓存具体是怎么实现的。所以我就写了个抽象的接口先,并清楚的描述此接口应该提供的服务,至于如何实现,一字没提。更加给力的是,在写那个具体的缓存类之前,依赖于它的这个模块的单元测试我也写好了。欢乐吧!最后,这个缓存怎么搞,我可以选择自己搞,也可以给外包出去,反正,协议都已经写好了。

好了,先小结一下,在这里接口的用处很明显,它定义了一个服务是什么,而不是说,服务是如何实现的。如此看来,写接口有利于专注在核心业务上,有利于软件的模块化,有利于增加代码的文档解释率,有利于提高模块的可测试性,并且还可以通过分布式工作加快开发进程。当然,一切的前提,是我们可以抽象出来我们所需要的服务。否则,都是扯淡。

现在再看第二种情形,我们需要把接口给删了吗?恐怕,想删都没那么容易了,为什么?因为,这个接口在测试里被用了,这个接口上有完善的文档。当然,估计也没多少人会提出要不要删它的这个问题。

得嘞,在看看开头的问题,是不是显得很幼稚?