資訊專欄INFORMATION COLUMN
摘要：實(shí)際上，本原則要求接口必須是粒度明確的。當(dāng)你的代碼不符合接口分離原則時(shí)，那也肯定違背了單一責(zé)任原則。接口分離原則本原則是指在實(shí)現(xiàn)類中對(duì)于接口中的方法并不強(qiáng)制去實(shí)現(xiàn)使用不到的方法。
聲明：本文并非博主原創(chuàng)，而是來(lái)自對(duì)《Laravel 4 From Apprentice to Artisan》閱讀的翻譯和理解，當(dāng)然也不是原汁原味的翻譯，能保證90%的原汁性，另外因?yàn)槭抢斫夥g，肯定會(huì)有錯(cuò)誤的地方，歡迎指正。
歡迎轉(zhuǎn)載，轉(zhuǎn)載請(qǐng)注明出處，謝謝！
接口分離原則 介紹接口分離原則指在實(shí)現(xiàn)類中對(duì)于接口中的方法并不強(qiáng)制去實(shí)現(xiàn)使用不到的方法。事實(shí)上，在平時(shí)的代碼中，你也難道也實(shí)現(xiàn)了那些你不需要使用的接口方法？如果是，也是流程空方法吧。這其實(shí)已經(jīng)違背了接口分離原則。
實(shí)際上，本原則要求接口必須是粒度明確的。聽(tīng)起來(lái)是否似曾相識(shí)？是的，SOLID原則都是相關(guān)的，打破其中一條，基本上你也就打破了其他原則。當(dāng)你的代碼不符合接口分離原則時(shí)，那也肯定違背了單一責(zé)任原則。
代替這種在實(shí)現(xiàn)類中包含很多“笨重”方法的接口，我們把他劃分成很多細(xì)小需要集成的多個(gè)接口。通過(guò)把臃腫的接口切成小的，細(xì)分的約定，使代碼可以繼承較小的接口，而不需創(chuàng)建引用中不需要依賴的部分。
實(shí)探接口分離原則
本原則是指在實(shí)現(xiàn)類中對(duì)于接口中的方法并不強(qiáng)制去實(shí)現(xiàn)使用不到的方法。
為了闡述該原則，我們來(lái)以會(huì)話處理類庫(kù)舉例。實(shí)際上，我們參考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實(shí)現(xiàn)的解決方案。是不是以Memcached實(shí)現(xiàn)的接口類必須將所有方法實(shí)現(xiàn)？我們不僅不需要實(shí)現(xiàn)所有的方法，其中一般都不需要處理！
Memcached有自己的自動(dòng)過(guò)期機(jī)制，因此我們不需要實(shí)現(xiàn)接口的gc方法，也不需要實(shí)現(xiàn)open或者close方法。這里我們只需定義一個(gè)空方法。為了糾正這個(gè)問(wèn)題，我們來(lái)定義一個(gè)更小，更專注的接口來(lái)進(jìn)行session垃圾回收：
interface GarbageCollectorInterface {
public function gc($maxLifetime);
}
現(xiàn)在接口已經(jīng)很小，所有相關(guān)代碼都能依賴這個(gè)專們的約定，它定義了一個(gè)專門的函數(shù)無(wú)需處理所有的session操作。
我們來(lái)以另外一個(gè)例子來(lái)加深對(duì)該原則的理解。這里有一個(gè)ContactEloquent類是這樣定義的：
class Contact extends Eloquent {
public function getNameAttribute()
{
return $this->attributes["name"];
}
public function getEmailAttribute()
{
return $this->attributes["email"];
}
}
現(xiàn)在，假定應(yīng)用同樣使用了PasswordReminder類來(lái)發(fā)送密碼提醒郵件給用戶。下面是PasswordReminder可能的一種實(shí)現(xiàn)類：
class PasswordReminder {
public function remind(Contact $contact, $view)
{
// Send password reminder e-mail...
}
}
你應(yīng)該已經(jīng)注意到，PasswordReminder以來(lái)了Contact類，也就意味著他依賴了Eloquent ORM。這種特殊的以O(shè)RM實(shí)現(xiàn)的密碼提醒系統(tǒng)來(lái)說(shuō)是不合理也是不需要的。在這種依賴之外，我們能自由的切換后臺(tái)存儲(chǔ)機(jī)制或者ORM而不用改變現(xiàn)有的密碼提醒組件。又一次，我們破壞了SOLID原則，現(xiàn)有的類對(duì)應(yīng)用中的其他“認(rèn)知”知道的太多了。
為了打破這種依賴，我們來(lái)創(chuàng)建一個(gè)RemindableInterface接口。實(shí)際上，這個(gè)接口已經(jīng)包含在Laravel中了，默認(rèn)已經(jīng)實(shí)現(xiàn)在User模型中了：
interface RemindableInterface {
public function getReminderEmail();
}
接口一旦創(chuàng)建完畢，我們就可以在模型中來(lái)實(shí)現(xiàn)他：
class Contact extends Eloquent implements RemindableInterface {
public function getReminderEmail()
{
return $this->email;
}
}
最終，我們只須要依賴這個(gè)結(jié)構(gòu)更小，功能更專注的PasswordReminder接口：
class PasswordReminder {
public function remind(RemindableInterface $remindable, $view)
{
// Send password reminder e-mail...
}
}
簡(jiǎn)單的改變，我們的類實(shí)現(xiàn)新的RemindableInterface之后，我們就將密碼提醒組件中不需要的依賴剔除，相對(duì)ORM就更加具有靈活性了。這也是Laravel在數(shù)據(jù)庫(kù)和ORM之外對(duì)密碼提醒組件的實(shí)現(xiàn)。
只是就是力量
再次地，我們發(fā)現(xiàn)類中太多的實(shí)現(xiàn)細(xì)節(jié)帶來(lái)的陷阱。對(duì)類中給定的職責(zé)多加注意，我們就能很好的遵守SOLID設(shè)計(jì)原則。
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://m.hztianpu.com/yun/23042.html
摘要：然而，我們需要注意的是僅是軟件設(shè)計(jì)模式依賴注入的一種便利的實(shí)現(xiàn)形式。容器本身不是依賴注入的必要條件，在框架他只是讓其變得更加簡(jiǎn)便。首先，讓我們探索下為什么依賴注入是有益的。繼續(xù)深入讓我們通過(guò)另一個(gè)示例來(lái)加深對(duì)依賴注入的理解。 聲明：本文并非博主原創(chuàng)，而是來(lái)自對(duì)《Laravel 4 From Apprentice to Artisan》閱讀的翻譯和理解，當(dāng)然也不是原汁原味的翻譯，能保證9...
摘要：它是良好應(yīng)用設(shè)計(jì)的大原則，包含單一責(zé)任原則開(kāi)放封閉原則里氏替換原則接口分離原則依賴倒置原則讓我們通過(guò)代碼示例來(lái)深究下這五個(gè)原則。實(shí)探單一責(zé)任原則代表一個(gè)類有且僅有一個(gè)改變的原因，換言之，一個(gè)類的職責(zé)范疇是嚴(yán)謹(jǐn)明確的。 聲明：本文并非博主原創(chuàng)，而是來(lái)自對(duì)《Laravel 4 From Apprentice to Artisan》閱讀的翻譯和理解，當(dāng)然也不是原汁原味的翻譯，能保證90%的原...
摘要：在改變存儲(chǔ)系統(tǒng)的情況下，必須對(duì)進(jìn)行修改，違背了開(kāi)放封閉原則。傳統(tǒng)的依賴痛過(guò)倒置就能事代碼變得非常靈活，易于改變 聲明：本文并非博主原創(chuàng)，而是來(lái)自對(duì)《Laravel 4 From Apprentice to Artisan》閱讀的翻譯和理解，當(dāng)然也不是原汁原味的翻譯，能保證90%的原汁性，另外因?yàn)槭抢斫夥g，肯定會(huì)有錯(cuò)誤的地方，歡迎指正。 歡迎轉(zhuǎn)載，轉(zhuǎn)載請(qǐng)注明出處，謝謝！ 依賴反轉(zhuǎn)原則 ...
摘要：里氏替換原則該原則表示，程序中對(duì)于實(shí)例化對(duì)象的子類型，不需要修改代碼，可以直接進(jìn)行替換。上述實(shí)例已違背里氏替換原則。我們的數(shù)據(jù)庫(kù)獲取部分就是破壞里氏替換的點(diǎn)，在你以后的編碼中一定要對(duì)這種編碼留心 聲明：本文并非博主原創(chuàng)，而是來(lái)自對(duì)《Laravel 4 From Apprentice to Artisan》閱讀的翻譯和理解，當(dāng)然也不是原汁原味的翻譯，能保證90%的原汁性，另外因?yàn)槭抢斫夥?..
摘要：如果在設(shè)計(jì)中，能正確使用開(kāi)放封閉原則，就能很好的規(guī)避這些問(wèn)題。開(kāi)放封閉原則設(shè)計(jì)原則中的開(kāi)放封閉原則是指代碼對(duì)擴(kuò)展開(kāi)放，對(duì)修改關(guān)閉。實(shí)探我們以上章中的為基礎(chǔ)，繼續(xù)來(lái)探究開(kāi)放封閉原則。在進(jìn)一步處理之前，要知道開(kāi)閉原則并非硬規(guī)定。 聲明：本文并非博主原創(chuàng)，而是來(lái)自對(duì)《Laravel 4 From Apprentice to Artisan》閱讀的翻譯和理解，當(dāng)然也不是原汁原味的翻譯，能保證9...
閱讀 2022·2021-11-22 15:29
閱讀 3320·2021-10-14 09:43
閱讀 1309·2021-10-08 10:22
閱讀 3400·2021-08-30 09:46
閱讀 1481·2019-08-30 15:55
閱讀 1978·2019-08-30 15:44
閱讀 908·2019-08-30 14:19
閱讀 1512·2019-08-30 13:13
