大圣Blog

设计模式

面向对象

设计原则

创建型

结构型

行为型

其他

课程导航

接口与抽象类

## 什么是"接口"

“接口”就是一组“协议”或者“约定”，是功能提供者提供给使用者的一个“功能列表”。“基于接口而非实现编程”这条原则中的“接口”，可以理解为编程语言中的接口或者抽象类。

应用这条原则，可以将接口和实现相分离，封装不稳定的实现，暴露稳定的接口。上游系统面向接口而非实现编程，不依赖不稳定的实现细节，这样当实现发生变化的时候，上游系统的代码基本上不需要做改动，以此来降低耦合性，提高扩展性。

实际上，“基于接口而非实现编程”这条原则的另一个表述方式，是“**基于抽象而非实现编程**”。后者的表述方式其实更能体现这条原则的设计初衷。在软件开发中，最大的挑战之一就是需求的不断变化，这也是考验代码设计好坏的一个标准。**越抽象、越顶层、越脱离具体某一实现的设计，越能提高代码的灵活性，越能应对未来的需求变化。好的代码设计，不仅能应对当下的需求，而且在将来需求发生变化的时候，仍然能够在不破坏原有代码设计的情况下灵活应对。**

## 案例

系统运行的信息、系统的错误信息等都会存储在日志中，日志存储的媒介有文本、数据库（如redis、mongodb、mysql）、远程系统等。

假如系统刚开始是使用文本文件来创建日志，下面是具体的实现

```php
class TextLog
{
    public function makeDir (string $dirName) :void
    {

}

public function mkTxt (string $txtName) :void
    {

}

public function write (string $msg)
    {

}
}

// 使用举例
$dirName = './logs';
$txtName = '1.txt';
$log = new TextLog();
$log->makeDir($dirName);
$log->mkTxt($txtName);
$log->write('something...');
```

上面的日志类实现非常简单，分为3步，首先创建目录，然后创建文本文件，最后向文本文件中写入内容。

但如果今后，我们不使用文本文件来作为存储介质，而改为使用Redis来保存，那么我们该如何来修改代码，让系统改动最小呢？这有点困难，因为我们上面的代码至少包含两个“细节”——makeDir以及mkTxt。使用Redis来存日志的流程会和文本文件不一样，所以，我们很难做到小改动。所以，如果重新创建一个RedisLog，之前涉及到的日志存储的代码改动都会非常大。

那如果解决上面的问题呢？我们需要做到3点：

* 函数的命令不能暴露任何实现细节。比如makeDir以及mkTxt这两个方法。
* 封装具体的实现细节，比如和文本文件相关的makeDir以及mkTxt不应该暴露给使用者，我们应该对日志记录流程进行封装，对外提供一个包括具体细节的方法，给调用者使用
* 为实现类定义抽象的接口。具体的实现类都依赖统一的接口定义，遵从一致的上传功能协议。使用者依赖接口，而不是具体的实现类来编程。

现在，我们按照上面的思路，把代码重构下，重构后的代码如下：

```php
interface Log
{
    function write (string $msg);
}

class TextLog implements Log
{
    public function __construct($dirname, $txtname)
    {
        $this->makeDir($dirname);
        $this->mkTxt($txtname);
    }

private function makeDir (string $dirName) :void
    {
        // do something
    }

private function mkTxt (string $txtName) :void
    {
        // do something
    }

public function write (string $msg)
    {

}
}

class RedisLog implements Log
{
    private $redis = null;
    private $key = '';

public function __construct(string $key)
    {
        $this->redis = '...'; // 获取redis实例
        $this->key = $key;
        // ...
    }

public function write (string $msg)
    {

}
}
```

总结一下，我们在做软件开发的时候，一定要有抽象意识、封装意识、接口意识。在定义接口的时候，不要暴露任何实现细节。接口的定义只表明做什么，而不是怎么做。而且，在设计接口的时候，我们要多思考一下，这样的接口设计是否足够通用，是否能够做到在替换具体的接口实现的时候，不需要任何接口定义的改动。

## 是否需要为每个类定义接口

看了刚刚的讲解，你可能会有这样的疑问：为了满足这条原则，我是不是需要给每个实现类都定义对应的接口呢？在开发的时候，是不是任何代码都要只依赖接口，完全不依赖实现编程呢？

做任何事情都要讲求一个“度”，过度使用这条原则，非得给每个类都定义接口，接口满天飞，也会导致不必要的开发负担。至于什么时候，该为某个类定义接口，实现基于接口的编程，什么时候不需要定义接口，直接使用实现类编程，我们做权衡的根本依据，还是要回归到设计原则诞生的初衷上来。只要搞清楚了这条原则是为了解决什么样的问题而产生的，你就会发现，很多之前模棱两可的问题，都会变得豁然开朗。

前面我们也提到，这条原则的设计初衷是，将接口和实现相分离，封装不稳定的实现，暴露稳定的接口。上游系统面向接口而非实现编程，不依赖不稳定的实现细节，这样当实现发生变化的时候，上游系统的代码基本上不需要做改动，以此来降低代码间的耦合性，提高代码的扩展性。

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

除此之外，越是不稳定的系统，我们越是要在代码的扩展性、维护性上下功夫。相反，如果某个系统特别稳定，在开发完之后，基本上不需要做维护，那我们就没有必要为其扩展性，投入不必要的开发时间。

接口与抽象类

设计模式

课程导航

什么是面向接口编程

文章目录