摘要:實際上,本原則要求接口必須是粒度明確的。當你的代碼不符合接口分離原則時,那也肯定違背了單一責任原則。接口分離原則本原則是指在實現類中對于接口中的方法并不強制去實現使用不到的方法。
聲明:本文并非博主原創,而是來自對《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設計原則。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/23042.html
摘要:然而,我們需要注意的是僅是軟件設計模式依賴注入的一種便利的實現形式。容器本身不是依賴注入的必要條件,在框架他只是讓其變得更加簡便。首先,讓我們探索下為什么依賴注入是有益的。繼續深入讓我們通過另一個示例來加深對依賴注入的理解。 聲明:本文并非博主原創,而是來自對《Laravel 4 From Apprentice to Artisan》閱讀的翻譯和理解,當然也不是原汁原味的翻譯,能保證9...
摘要:它是良好應用設計的大原則,包含單一責任原則開放封閉原則里氏替換原則接口分離原則依賴倒置原則讓我們通過代碼示例來深究下這五個原則。實探單一責任原則代表一個類有且僅有一個改變的原因,換言之,一個類的職責范疇是嚴謹明確的。 聲明:本文并非博主原創,而是來自對《Laravel 4 From Apprentice to Artisan》閱讀的翻譯和理解,當然也不是原汁原味的翻譯,能保證90%的原...
摘要:在改變存儲系統的情況下,必須對進行修改,違背了開放封閉原則。傳統的依賴痛過倒置就能事代碼變得非常靈活,易于改變 聲明:本文并非博主原創,而是來自對《Laravel 4 From Apprentice to Artisan》閱讀的翻譯和理解,當然也不是原汁原味的翻譯,能保證90%的原汁性,另外因為是理解翻譯,肯定會有錯誤的地方,歡迎指正。 歡迎轉載,轉載請注明出處,謝謝! 依賴反轉原則 ...
摘要:里氏替換原則該原則表示,程序中對于實例化對象的子類型,不需要修改代碼,可以直接進行替換。上述實例已違背里氏替換原則。我們的數據庫獲取部分就是破壞里氏替換的點,在你以后的編碼中一定要對這種編碼留心 聲明:本文并非博主原創,而是來自對《Laravel 4 From Apprentice to Artisan》閱讀的翻譯和理解,當然也不是原汁原味的翻譯,能保證90%的原汁性,另外因為是理解翻...
摘要:如果在設計中,能正確使用開放封閉原則,就能很好的規避這些問題。開放封閉原則設計原則中的開放封閉原則是指代碼對擴展開放,對修改關閉。實探我們以上章中的為基礎,繼續來探究開放封閉原則。在進一步處理之前,要知道開閉原則并非硬規定。 聲明:本文并非博主原創,而是來自對《Laravel 4 From Apprentice to Artisan》閱讀的翻譯和理解,當然也不是原汁原味的翻譯,能保證9...
閱讀 1956·2021-11-22 15:29
閱讀 3252·2021-10-14 09:43
閱讀 1223·2021-10-08 10:22
閱讀 3342·2021-08-30 09:46
閱讀 1431·2019-08-30 15:55
閱讀 1923·2019-08-30 15:44
閱讀 849·2019-08-30 14:19
閱讀 1439·2019-08-30 13:13