### 簡介
接口隔離原則規定,不應該強制接口的實現依賴于它不使用的方法。你是否曾被迫去實現一些你用不到的接口方法?如果答案是肯定的,那么你可能會在實現里創建一個空方法。這就是一個使用了違背接口隔離原則的接口的例子。
在實際操作中,這個原則要求接口必須粒度很細,且專注于一個領域。聽起來很耳熟?記住,所有五個「SOLID」原則都是相關的,也就是說違背了其中一個原則,通常意味著也違背了其他的原則。當你違背了接口隔離原則,肯定也違背了單一職責原則。
與其保有一個包含不是所有實現都需要的方法的「臃腫」接口,不如將其拆分成多個更細粒度的接口,然后各自按需獨立實現。這樣將臃腫接口拆分成細粒度、功能集中的接口后,調用方也可以依賴更小的接口,而不必為我們不需要的功能買單。
### 實踐
為了說明該原則,我們來看一個會話處理類庫的例子。實際上,我們將要考察 PHP 自帶的 `SessionHandlerInterface`。下面是該接口定義的方法,它們是從 PHP 5.4 版才開始有的:
```php
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 數據的接口:
```php
interface GarbageCollectorInterface
{
public function gc($maxLifetime);
}
```
現在我們有了一個更細粒度的接口,功能單一而專注。調用方只需要依賴它就可以了,而不必去依賴整個會話處理器。
為了更深入理解該原則,我們用另一個例子來強化理解。想象我們有一個名為`Contact` 的 Eloquent 模型類,定義成這樣:
```php
class Contact extends Eloquent
{
public function getNameAttribute()
{
return $this->attributes['name'];
}
public function getEmailAttribute()
{
return $this->attributes['email'];
}
}
```
現在,我們再假設應用里還有一個叫 `PasswordReminder` 的類來負責給用戶發送密碼找回郵件。下面是 `PasswordReminder` 類一種可能的定義方式:
```php
class PasswordReminder
{
public function remind(Contact $contact, $view)
{
// Send password reminder e-mail...
}
}
```
你可能注意到了,`PasswordReminder` 依賴 `Contact` 類,也就是依賴 Eloquent ORM。將密碼找回系統和一個特定的 ORM 實現耦合到一起實在是沒必要,也是不可取的。切斷這個依賴后,就可以自由地改變后臺存儲機制或者 ORM,同時不會對密碼找回組件造成影響。重申一遍,違背了「SOLID」原則的任何一條,都會導致調用方了解更多應用其它部分的它不改知道的實現細節。
要切斷這種依賴,需要創建一個 `RemindableInterface` 接口。事實上,Laravel 已經自帶了這個接口,并且默認被 `User` 模型類實現:
```php
interface RemindableInterface
{
public function getReminderEmail();
}
```
```
interface RemindableInterface
```
2
```
{
```
3
```
public function getReminderEmail();
```
4
```
}
```
接口創建好了之后,我們就可以在模型類中實現它:
```php
class Contact extends Eloquent implements RemindableInterface
{
public function getReminderEmail()
{
return $this->email;
}
}
```
這樣,我們就可以在 `PasswordReminder` 里面依賴這個小巧且專注的接口了:
```php
class PasswordReminder
{
public function remind(RemindableInterface $remindable, $view)
{
// Send password reminder e-mail...
}
}
```
通過這樣的改動之后,我們已經移除了密碼找回組件里不必要的依賴,并且使它足夠靈活,可以使用任何實現了 `RemindableInterface` 接口的類或 ORM。這其實正是 Laravel 密碼找回組件如何保持與數據庫和 ORM 無關的秘訣!
> 我們再一次發現了讓類過多地了解應用程序實現細節的缺陷。通過仔細觀察我們在類中暴露的實現細節,我們就可以遵守所有 SOLID 原則。