国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

讀懂 SOLID 的「接口隔離」原則

wing324 / 919人閱讀

摘要：接口隔離原則是什么客戶端代碼不應(yīng)當(dāng)被迫依賴于它們不需要的方法。

這是理解SOLID原則，關(guān)于接口隔離原則如何幫助我們創(chuàng)建簡(jiǎn)單的抽象接口，并使客戶端代與接口之間存在的更少的依賴關(guān)系。
接口隔離原則是什么 
Clients should not be forced to depend on methods that they do not use.
客戶端代碼不應(yīng)當(dāng)被迫依賴于它們不需要的方法。

這個(gè)原則本身與單一職責(zé)原則關(guān)系十分緊密，它意味著當(dāng)你在定義你的抽象層代碼時(shí)，不應(yīng)當(dāng)在客戶端代碼在實(shí)現(xiàn)抽象邏輯時(shí)，暴露一些客戶端代碼不需要使用或者關(guān)心的方法。

進(jìn)一步說明的話，就是當(dāng)你有意地在抽象層中暴露的方法時(shí)，這意味著所有實(shí)現(xiàn)這些抽象邏輯的客戶端代碼都必須要實(shí)現(xiàn)所有的抽象方法，盡管這些方法并不一定都對(duì)客戶端代碼有意義。

將你的接口的保持精簡(jiǎn)和小顆粒度，并且不要在它們中間增加無用的抽象方法，當(dāng)你在對(duì)新的抽象接口進(jìn)行命名時(shí)，你就會(huì)擁有更好的選擇，因?yàn)槟阋延辛巳舾尚☆w粒的命名類型。這樣做的意義在于當(dāng)你在需要提供一個(gè)更加大顆粒度的抽象接口時(shí)，你可以擁有足夠的靈活性來將已有的小顆粒度接口進(jìn)行組合。

如何實(shí)踐接口隔離原則

這個(gè)例子是關(guān)于一個(gè)ATM用戶界面的抽象接口，這個(gè)接口會(huì)處理諸如存款請(qǐng)求、取款請(qǐng)求等邏輯，從這個(gè)例子中我們會(huì)了解到，我們?nèi)绾螌?duì)這個(gè)接口進(jìn)行隔離，使其進(jìn)一步劃分為多個(gè)獨(dú)立的、更加具體的若干接口。

首先我們應(yīng)當(dāng)有一個(gè)工具函數(shù)庫(kù)接口，這個(gè)接口會(huì)描述我們想要暴露的關(guān)于byte操作邏輯的方法，讓我們創(chuàng)建這樣一個(gè)接口，如下

type ByteUtils interface {
    Read(b []byte) (n int, err error) // Read into buffer
    Write(b []byte)(n int, err error) // Write into buffer
    Trim(b []byte, exclusions string)[]byte // Trim buffer by removing bytes from the exclusion chars
}

它可以正常工作一段時(shí)間，但是很快我們就會(huì)發(fā)現(xiàn)以下兩個(gè)問題：

它的命名ByteUtils太過于通用，如果我們僅通過命名本身，基本無法獲取任何具體的信息

當(dāng)使用它時(shí)，會(huì)有一些古怪的感覺，因?yàn)楫?dāng)你根據(jù)不同的優(yōu)化場(chǎng)景來按不同邏輯實(shí)現(xiàn)trim方法時(shí)，你所實(shí)現(xiàn)的read和write幾乎沒什么差別，但是你卻需要重復(fù)地實(shí)現(xiàn)它們，同時(shí)在某些不需要讀或者寫的場(chǎng)景，仍然需要實(shí)現(xiàn)它們。

所以它雖然能夠正常工作，但是卻不夠好。

我們可以通過創(chuàng)建三個(gè)更精簡(jiǎn)、更具體的接口來替代原先通用的接口：

type Reader interface {
    Read(b []byte) (n int, err error) 
}
type Writer interface {
    Write(b []byte)(n int, err error) 
}
type Trimmer interface {
    Trim(b []byte, exclusions string)[]byte 
}

這種顆粒度比較細(xì)的接口也可以稱為角色接口，因?yàn)樗鼈兏子谥貥?gòu)和改變，甚至對(duì)于已經(jīng)定義好的角色和目的也可以很容易的進(jìn)行重新部署和定義。

在這三個(gè)基礎(chǔ)上，我們可以通過組合它們來獲取一個(gè)更有關(guān)聯(lián)性的接口列表，比如：

type ReadWriter interface {
    Reader
    Writer 
}
type TrimReader interface {
    Trimmer
    Reader
}

這意味客戶端代碼擁有了可以根據(jù)它們各自的需求來組合抽象層接口的靈活性，這樣就會(huì)避免在實(shí)現(xiàn)抽象接口時(shí)不必要的麻煩（比如必須要實(shí)現(xiàn)某些無用的方法），比如上面的TrimReader的實(shí)現(xiàn)并未包含多余的Write方法的聲明。

總結(jié)

正如你所看到的，通用的接口往往會(huì)無意識(shí)的將自己和類的實(shí)現(xiàn)耦合在了一起，所以你應(yīng)當(dāng)盡量的避免這種情況的發(fā)生。在設(shè)計(jì)接口時(shí)，你應(yīng)當(dāng)時(shí)刻提醒自己，我是否需要使用所有在接口中聲明的方法呢？如果不是的話，將接口細(xì)分為更多個(gè)更精簡(jiǎn)、更具體的接口。

正如甘地曾經(jīng)說過：

你的行動(dòng)決定你的習(xí)慣，你的習(xí)慣決定你的價(jià)值，你的價(jià)值會(huì)決定你的命運(yùn)。

如果在架構(gòu)中，你每次都會(huì)經(jīng)過仔細(xì)思考，會(huì)按照好的模式來進(jìn)行設(shè)計(jì)，它將會(huì)成為一種習(xí)慣，自然慢慢會(huì)轉(zhuǎn)變?yōu)槟愕膬r(jià)值或者原則，最終則會(huì)成為你的命運(yùn)，比如成為了一個(gè)始終給予完善解決方案的軟件架構(gòu)師。

我的觀點(diǎn)是，始終通過挑戰(zhàn)自己來變的更好，在某些時(shí)刻，你可能會(huì)遇到問題，但是往往你可能已經(jīng)擁有了答案。

Happy coding!

譯者注

對(duì)于接口隔離原則的理解，我一直覺的它本身其實(shí)是單一職責(zé)原則的一個(gè)擴(kuò)展，但是它們之間也有細(xì)微的不同：

單一職責(zé)原則往往面向?qū)崿F(xiàn)層，比如具體的類或者某個(gè)方法

接口隔離原則往往面向抽象層，比如一些抽象類或者抽象方法

所以將兩個(gè)原則結(jié)合起來看的話，可以很容器得到當(dāng)時(shí)提出這兩個(gè)原則的人的意圖，那就是一定要時(shí)刻保持簡(jiǎn)單。

在實(shí)際工作中，我深知保持簡(jiǎn)單是一件十分困難的事情，因?yàn)楣こ處煴旧淼氖姑闶墙鉀Q問題，而問題往往充滿了未知性，而未知性往往代表著改變，這還沒有考慮到在項(xiàng)目實(shí)施過程中，產(chǎn)品經(jīng)理天馬行空的設(shè)計(jì)思路，客戶們五花八門的需求等等。在這些外界條件下，我們的代碼往往會(huì)變得復(fù)雜無比，充滿了各種反模式和冗余代碼，最終會(huì)使自己陷入無盡的bug修復(fù)和維護(hù)工作中，怎么還會(huì)有時(shí)間進(jìn)行自我提升呢？

所以，為了能夠按時(shí)下班，為了能夠及早回家，為了能夠讓我們的擁有更多的時(shí)間來提升自己和陪伴家人，在軟件設(shè)計(jì)之初，盡可能地針對(duì)將來所面臨的改變，在設(shè)計(jì)層面降低軟件抽象模塊間的耦合程度，在項(xiàng)目實(shí)施時(shí)，提高每個(gè)具體實(shí)現(xiàn)模塊內(nèi)部的內(nèi)聚程度，同時(shí)使它們保持簡(jiǎn)單，這樣便是一個(gè)好的開始。

關(guān)注公眾號(hào) 全棧101，只談技術(shù)，不談人生

文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請(qǐng)注明本文地址：http://m.specialneedsforspecialkids.com/yun/107333.html

相關(guān)文章

  • 讀懂 SOLID 的「里氏替換」原則

    摘要：什么是里氏替換原則某個(gè)對(duì)象實(shí)例的子類實(shí)例應(yīng)當(dāng)可以在不影響程序正確性的基礎(chǔ)上替換它們。除了在編程語(yǔ)言層面，在前端實(shí)際工作中，你可能會(huì)聽到一個(gè)叫作的概念，這個(gè)概念我認(rèn)為也是里氏替換原則的一直延伸。 這是理解SOLID原則，關(guān)于里氏替換原則為什么提倡我們面向抽象層編程而不是具體實(shí)現(xiàn)層，以及為什么這樣可以使代碼更具維護(hù)性和復(fù)用性。 什么是里氏替換原則 Objects should be rep...

    vibiu 評(píng)論0 收藏0

  • 讀懂 SOLID 的「依賴倒置」原則

    這是理解SOLID原則中，關(guān)于依賴倒置原則如何幫助我們編寫低耦合和可測(cè)試代碼的第一篇文章。 寫在前頭 當(dāng)我們?cè)谧x書，或者在和一些別的開發(fā)者聊天的時(shí)候，可能會(huì)談及或者聽到術(shù)語(yǔ)SOILD。在這些討論中，一些人會(huì)提及它的重要性，以及一個(gè)理想中的系統(tǒng)，應(yīng)當(dāng)包含它所包含的5條原則的特性。 我們?cè)诿看蔚墓ぷ髦?，你可能沒有那么多時(shí)間思考關(guān)于架構(gòu)這個(gè)比較大的概念，或者在有限的時(shí)間內(nèi)或督促下，你也沒有辦法實(shí)踐一些好...

    Snailclimb 評(píng)論0 收藏0

  • 讀懂 SOLID 的「開閉」原則

    摘要：事件驅(qū)動(dòng)模型對(duì)于一些復(fù)雜的事件驅(qū)動(dòng)模型，比如拖拽，往往使用開閉原則會(huì)達(dá)到意想不到的效果。 這是理解SOLID原則，介紹什么是開閉原則以及它為什么能夠在對(duì)已有的軟件系統(tǒng)或者模塊提供新功能時(shí)，避免不必要的更改（重復(fù)勞動(dòng)）。 開閉原則是什么 Software entities (classes, modules, functions, etc.) should be open for ext...

    awkj 評(píng)論0 收藏0

  • PHP面向?qū)ο笤O(shè)計(jì)五大原則（SOLID）梳理總結(jié)

    摘要：設(shè)計(jì)原則梳理，參考核心技術(shù)與最佳實(shí)踐敏捷開發(fā)原則模式與實(shí)踐，文章面向?qū)ο笤O(shè)計(jì)的五大原則設(shè)計(jì)模式原則單一職責(zé)原則定義特性僅有一個(gè)引起類變化的原因一個(gè)類只承擔(dān)一項(xiàng)職責(zé)職責(zé)變化的原因避免相同的職責(zé)分散到不同的類，功能重復(fù)問題一個(gè)類承擔(dān)的職責(zé)過多， PHP設(shè)計(jì)原則梳理，參考《PHP核心技術(shù)與最佳實(shí)踐》、《敏捷開發(fā)原則、模式與實(shí)踐》，文章PHP面向?qū)ο笤O(shè)計(jì)的五大原則、設(shè)計(jì)模式原則SOLID 單一...

    王晗 評(píng)論0 收藏0

發(fā)表評(píng)論

0條評(píng)論

最新活動(dòng)
閱讀需要支付1元查看
<