声明：本文非博主原创，来自《Laravel 4 From Apprentice to Artisan》阅读的翻译理解。当然不是原译，可以保证90%的原创性。另外，由于是理解翻译，难免有错误，欢迎指正。欢迎转载，转载请注明出处，谢谢！接口分离原则介绍接口分离原则，是指在实现类中，不强制接口中的方法去实现不能使用的方法。其实在平时的代码中，是不是也实现了那些不需要用到的接口方法呢？如果是这样，它也是一个进程空方法。这实际上违反了接口分离的原则。事实上，这个原则要求接口必须是细粒度的。这听起来很熟悉吗？是的，SOLID原则都是相关的，破坏一个原则基本上也会破坏其他原则。当你的代码不符合接口分离原则的时候，一定也违反了单一职责原则。而不是这种在实现类中包含很多“笨重”方法的接口，我们把它分成很多需要集成的小接口。通过将臃肿的接口切割成小的、细分的契约，代码可以继承更小的接口，而无需创建不需要依赖部件的引用。接口分离原则这个原则是指在实现类中，接口中的方法不强制实现不能使用的方法。真实探索为了说明这个原理，我们以会话处理类库为例。其实我们参考的是PHP自带的SessionHandlerInterface接口。下面是PHP5.4中接口定义的方法：interfaceSessionHandlerInterface{publicfunctionclose();公共函数销毁（$sessionId）；公共功能gc($maxLiftetime);公共功能开放（$savePath，$name）；公共函数读取（$sessionId）；publicfunctionwrite($sessionId,$sessionData);}这些接口中的方法很熟悉，所以考虑基于Memcached的解决方案。Memcached实现的接口类是否必须实现所有方法？我们不仅不需要实现所有方法，而且一般都不需要处理！Memcached有自己的自动过期机制，所以我们不需要实现接口的gc方法，也不需要实现open或者close方法。这里我们只需要定义一个空方法。为了纠正这个问题，让我们为会话垃圾收集定义一个更小、更专注的接口：不需要处理所有会话操作的特殊函数。下面再举一个例子来加深对这个原理的理解。这是一个ContactEloquent类，定义如下：}publicfunctiongetEmailAttribute(){return$this->attributes['email'];现在，假设应用程序还使用PasswordReminder类向用户发送密码提醒电子邮件。下面是PasswordReminder一个可能的实现类：这意味着他依赖EloquentORM。这种特殊的基于ORM的密码提醒系统是不合理的，也没有必要。在这种依赖之外，我们可以自由切换后端存储机制或ORM，而无需更改现有的密码提醒组件。再一次，我们打破了SOLID原则，现有的类对应用程序中的其他“知识”了解得太多了。为了打破这种依赖关系，让我们创建一个RemindableInterface。其实这个接口已经包含在Laravel中，并且默认在User模型中实现了：Eloquent实现RemindableInterface{publicfunctiongetReminderEmail(){return$this->email;}}最后，我们只需要依赖这个结构更小、功能更集中的PasswordReminder接口即可：}}一个简单的改动，在我们的类实现了新的RemindableInterface之后，去掉了密码提醒组件中不必要的依赖，比ORM更加灵活。这也是Laravel在数据库和ORM之外实现的密码提醒组件。JustPower同样，我们发现类中有太多实现细节的缺陷。通过更多地关注课堂上给出的职责，我们可以很好地遵循SOLID设计原则。
