Laravel深入学习11 - 接口分离原则

lwx12525 发布于2019-06-27 16:39 / 831人阅读

摘要：实际上，本原则要求接口必须是粒度明确的。当你的代码不符合接口分离原则时，那也肯定违背了单一责任原则。接口分离原则本原则是指在实现类中对于接口中的方法并不强制去实现使用不到的方法。

声明：本文并非博主原创，而是来自对《Laravel 4 From Apprentice to Artisan》阅读的翻译和理解，当然也不是原汁原味的翻译，能保证90%的原汁性，另外因为是理解翻译，肯定会有错误的地方，欢迎指正。

欢迎转载，转载请注明出处，谢谢！

接口分离原则 介绍

接口分离原则指在实现类中对于接口中的方法并不强制去实现使用不到的方法。事实上，在平时的代码中，你也难道也实现了那些你不需要使用的接口方法？如果是，也是流程空方法吧。这其实已经违背了接口分离原则。

实际上，本原则要求接口必须是粒度明确的。听起来是否似曾相识？是的，SOLID原则都是相关的，打破其中一条，基本上你也就打破了其他原则。当你的代码不符合接口分离原则时，那也肯定违背了单一责任原则。

代替这种在实现类中包含很多“笨重”方法的接口，我们把他划分成很多细小需要集成的多个接口。通过把臃肿的接口切成小的，细分的约定，使代码可以继承较小的接口，而不需创建引用中不需要依赖的部分。

接口分离原则

本原则是指在实现类中对于接口中的方法并不强制去实现使用不到的方法。

实探

为了阐述该原则，我们来以会话处理类库举例。实际上，我们参考PHP自带的SessionHandlerInterface接口。下面是PHP5.4中接口定义的方法：

interface SessionHandlerInterface {
    public function close();
    public function destroy($sessionId);
    public function gc($maxLiftetime);
    public function open($savePath, $name);
    public function read($sessionId);
    public function write($sessionId, $sessionData);
}

这些接口中的方法很熟悉了吧，考虑基于Memcached实现的解决方案。是不是以Memcached实现的接口类必须将所有方法实现？我们不仅不需要实现所有的方法，其中一般都不需要处理！

Memcached有自己的自动过期机制，因此我们不需要实现接口的gc方法，也不需要实现open或者close方法。这里我们只需定义一个空方法。为了纠正这个问题，我们来定义一个更小，更专注的接口来进行session垃圾回收：

interface GarbageCollectorInterface {
    public function gc($maxLifetime);
}

现在接口已经很小，所有相关代码都能依赖这个专们的约定，它定义了一个专门的函数无需处理所有的session操作。

我们来以另外一个例子来加深对该原则的理解。这里有一个ContactEloquent类是这样定义的：

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设计原则。

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/23042.html

Laravel深入学习1 - 依赖注入

摘要：然而，我们需要注意的是仅是软件设计模式依赖注入的一种便利的实现形式。容器本身不是依赖注入的必要条件，在框架他只是让其变得更加简便。首先，让我们探索下为什么依赖注入是有益的。继续深入让我们通过另一个示例来加深对依赖注入的理解。声明：本文并非博主原创，而是来自对《Laravel 4 From Apprentice to Artisan》阅读的翻译和理解，当然也不是原汁原味的翻译，能保证9...

sunsmell 2019-06-27 15:49 评论0 收藏0
Laravel深入学习8 - 单一责任原则

摘要：它是良好应用设计的大原则，包含单一责任原则开放封闭原则里氏替换原则接口分离原则依赖倒置原则让我们通过代码示例来深究下这五个原则。实探单一责任原则代表一个类有且仅有一个改变的原因，换言之，一个类的职责范畴是严谨明确的。声明：本文并非博主原创，而是来自对《Laravel 4 From Apprentice to Artisan》阅读的翻译和理解，当然也不是原汁原味的翻译，能保证90%的原...

ymyang 2019-06-27 16:35 评论0 收藏0
Laravel深入学习12 - 依赖倒置原则

摘要：在改变存储系统的情况下，必须对进行修改，违背了开放封闭原则。传统的依赖痛过倒置就能事代码变得非常灵活，易于改变声明：本文并非博主原创，而是来自对《Laravel 4 From Apprentice to Artisan》阅读的翻译和理解，当然也不是原汁原味的翻译，能保证90%的原汁性，另外因为是理解翻译，肯定会有错误的地方，欢迎指正。欢迎转载，转载请注明出处，谢谢！依赖反转原则 ...

IamDLY 2019-06-27 16:38 评论0 收藏0
Laravel深入学习10 - 里氏替换原则

摘要：里氏替换原则该原则表示，程序中对于实例化对象的子类型，不需要修改代码，可以直接进行替换。上述实例已违背里氏替换原则。我们的数据库获取部分就是破坏里氏替换的点，在你以后的编码中一定要对这种编码留心声明：本文并非博主原创，而是来自对《Laravel 4 From Apprentice to Artisan》阅读的翻译和理解，当然也不是原汁原味的翻译，能保证90%的原汁性，另外因为是理解翻...

lijy91 2019-06-27 16:39 评论0 收藏0
Laravel深入学习9 - 开放封闭原则

摘要：如果在设计中，能正确使用开放封闭原则，就能很好的规避这些问题。开放封闭原则设计原则中的开放封闭原则是指代码对扩展开放，对修改关闭。实探我们以上章中的为基础，继续来探究开放封闭原则。在进一步处理之前，要知道开闭原则并非硬规定。声明：本文并非博主原创，而是来自对《Laravel 4 From Apprentice to Artisan》阅读的翻译和理解，当然也不是原汁原味的翻译，能保证9...

young.li 2019-06-27 16:35 评论0 收藏0