接口隔离原则
简介
接口隔离原则规定,不应该强制接口的实现依赖于它不使用的方法。你是否曾被迫去实现一些你用不到的接口方法?如果答案是肯定的,那么你可能会在实现里创建一个空方法。这就是一个使用了违背接口隔离原则的接口的例子。
在实际操作中,这个原则要求接口必须粒度很细,且专注于一个领域。听起来很耳熟?记住,所有五个「SOLID」原则都是相关的,也就是说违背了其中一个原则,通常意味着也违背了其他的原则。当你违背了接口隔离原则,肯定也违背了单一职责原则。
与其保有一个包含不是所有实现都需要的方法的「臃肿」接口,不如将其拆分成多个更细粒度的接口,然后各自按需独立实现。这样将臃肿接口拆分成细粒度、功能集中的接口后,调用方也可以依赖更小的接口,而不必为我们不需要的功能买单。
实践
为了说明该原则,我们来看一个会话处理类库的例子。实际上,我们将要考察 PHP 自带的 SessionHandlerInterface
。下面是该接口定义的方法,它们是从 PHP 5.4 版才开始有的:
interface SessionHandlerInterface {
public function close();
public function destroy($sessionId);
public function gc($maxLifetime);
public function open($savePath, $name);
public function read($sesssionId);
public function write($sessionId, $sessionData);
}
现在,我们已经知道接口里面都定义了什么方法了,我们打算基于 Memcached 来实现它。Memcached
实现类需要实现这个接口里的所有方法吗?不,里面一半的方法对于 Memcached 来说都是不需要实现的!
因为 Memcached 会自动清除存储的过期数据,我们不需要实现 gc
方法。我们也不需要实现 open
和 close
方法。所以,我们不得不在实现类中将相应的实现定义为空方法。为了解决在这个问题,我们来定义一个小巧的、专门用来回收过期 Session 数据的接口:
interface GarbageCollectorInterface
{
public function gc($maxLifetime);
}
现在我们有了一个更细粒度的接口,功能单一而专注。调用方只需要依赖它就可以了,而不必去依赖整个会话处理器。
为了更深入理解该原则,我们用另一个例子来强化理解。想象我们有一个名为Contact
的 Eloquent 模型类,定义成这样:
class Contact extends Eloquent
{
public function getNameAttribute()
{
return $this->attributes['name'];
}
public function getEmailAttribute()
{
return $this->attributes['email'];
}
}
现在,我们再假设应用里还有一个叫 PasswordReminder
的类来负责给用户发送密码找回邮件。下面是 PasswordReminder
类一种可能的定义方式:
class PasswordReminder
{
public function remind(Contact $contact, $view)
{
// Send password reminder e-mail...
}
}
你可能注意到了,PasswordReminder
依赖 Contact
类,也就是依赖 Eloquent ORM。将密码找回系统和一个特定的 ORM 实现耦合到一起实在是没必要,也是不可取的。切断这个依赖后,就可以自由地改变后台存储机制或者 ORM,同时不会对密码找回组件造成影响。重申一遍,违背了「SOLID」原则的任何一条,都会导致调用方了解更多应用其它部分的它不改知道的实现细节。
要切断这种依赖,需要创建一个 RemindableInterface
接口。事实上,Laravel 已经自带了这个接口,并且默认被 User
模型类实现:
interface RemindableInterface
{
public function getReminderEmail();
}
接口创建好了之后,我们就可以在模型类中实现它:
class Contact extends Eloquent implements RemindableInterface
{
public function getReminderEmail()
{
return $this->email;
}
}
这样,我们就可以在 PasswordReminder
里面依赖这个小巧且专注的接口了:
class PasswordReminder
{
public function remind(RemindableInterface $remindable, $view)
{
// Send password reminder e-mail...
}
}
通过这样的改动之后,我们已经移除了密码找回组件里不必要的依赖,并且使它足够灵活,可以使用任何实现了 RemindableInterface
接口的类或 ORM。这其实正是 Laravel 密码找回组件如何保持与数据库和 ORM 无关的秘诀!
我们再一次发现了让类过多地了解应用程序实现细节的缺陷。通过仔细观察我们在类中暴露的实现细节,我们就可以遵守所有 SOLID 原则。
5 Comments
看不懂:(
感觉应该是和接口产生依赖,而不是和某个具体实现产生依赖关系,我这么理解对吗。。
嗯 目的就是和具体实现解耦 面向接口开发 灵活性和可维护性要好很多
非常好,大受启发!
那如何调用remind()方法呢