### 簡介
接口隔離原則規定，不應該強制接口的實現依賴于它不使用的方法。你是否曾被迫去實現一些你用不到的接口方法？如果答案是肯定的，那么你可能會在實現里創建一個空方法。這就是一個使用了違背接口隔離原則的接口的例子。
在實際操作中，這個原則要求接口必須粒度很細，且專注于一個領域。聽起來很耳熟？記住，所有五個「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 原則。
