前言
前面介紹了單一職責原則、開放封閉原則、最少知識原則,今天要介紹的是Interface Segregation Principle, ISP (介面隔離原則)。
介面隔離原則,與單一職責原則和最少知識原則有一點關係,而SOLID原則的總綱是開放封閉原則,所以如果對這些觀念還不夠熟悉的朋友們,可以參考一下前面幾篇文章:
[ASP.NET]91之ASP.NET由淺入深 不負責講座 Day17 – 單一職責原則
[ASP.NET]91之ASP.NET由淺入深 不負責講座 Day18 – 開放封閉原則
[ASP.NET]91之ASP.NET由淺入深 不負責講座 Day19 – LoD/LKP 最少知識原則
1.定義
(1)Clients should not be forced to depend upon interfaces that they don't use.
也就是Client不應該依賴它不需要的介面。
(2)The dependency of one class to another one should depend on the smallest possible interface.
也就是Class之間的依賴關係應該建立在最小的interface上。
2.簡單的說
Class與外部的關係,應只依賴它需要的最小介面,所以介面不能太肥,應該要細化,不然會強迫中獎。每一個interface的方法數目應該盡可能地降到最低。
3.與單一職責原則的矛盾
(1)單一職責是指屬於同一個職責的方法應該放在一起,且一個class/interface只負責一個職責。
可能產生一種情況,實作interface的class,用不到該interface的所有方法。
(2)相對於介面隔離原則,則是每一個class實作了某個介面,就應該代表會用到該介面所有的方法,如果不會用到所有方法,代表該interface可以再繼續細化。
4.目的
對interface的scope進行約束。
5.基本原則
(1)interface盡量小
-粒度越小代表系統可以越靈活,但也代表結構越複雜,開發難度提升
-最小的情況就是一個interface只有一個method,但違反單一職責原則
-細分interface的前提,就是不能違反單一職責原則
(2)interface應高內聚
-粒度應該符合環境與未來需求中,細分到最細。
-interface就是contract的觀念,對外承諾的function越少,變動風險越低,就越穩定 。
(3)訂製服務
interface只提供訪問者需要的方法 。
(4)粒度大小的細分標準
因地因時制宜,取捨需求、開發與結構的平衡點 。
6.結論
殺雞焉用牛刀,但書:
(1)如果是為了殺雞,就不需要用到牛刀
(2)如果是為了用牛刀,那就還是得用牛刀
7.舉例
我們用下面這張class diagram(點圖可放大)來看,可以看到以工作上所需的技能來分,一個ExcellentWorker,應同時具備HardSkill與SoftSkill。
然而,不是每一樣工作,都需要excellent的worker才能做事。一個健康的團隊,應該有將有兵,分工合作,各司其職,互助互補。
如果今天工作需要的是協助測試,那可以找QA,也可以找Joey。最好是先找QA,因為如果找Joey,他的對外方法不只測試的介面,還有許多其他的功用,就很有可能被其他任務插單。
相對的,以介面來說,一個QA可能只需要具備測試的介面,而不需具備Leadership或是Integrity。
我自己的原則是,寧可多實作幾個interface,保留彈性,也要避免未來因為繼承或extend造成強耦合而無法修改的風險。
但interface的本身,還是要盡量符合單一職責的原則。
還是很抽象.
但這種東西要陳述也是不容易.
大家寫的也是很抽象.
介面是以外在溝通的管道.
UI是有畫面與人溝通的管道.
而這篇的Interface是無介面的管道.也就是二支(多支)元件或程式溝通的管道.
介面設計有非常多的原則.但如果你不是專業開發商,或你的元件沒有很多人共用其實不用想那麼複雜.有些原則也不用死背.
介面設計的好不好.
我的範例是車上的多媒體播放器.
有些很便宜的播放器只有幾個按鍵,然後做的大大的很容易操作,駕駛中操作也很安全.
有些高級轎車的播放器,功能很強,但20-30顆小小的按鈕,一看我就不想用.駕駛中東碰西碰無法按到要的功能,有些功能一輩子都用不到.
所以設計介面簡單明瞭就好了.(1)interface盡量小
在以多媒體播放器為例,有的媒體撥放器把相關功能放在同一區域,或一支操作桿,很直覺按幾下,轉幾圈就能達到你要的效果.
有的播放器是,左邊按鈕按一下,右邊按鈕按幾下,主畫面切子畫面,子畫面又左移右移.而且操作流程都不順暢.(2)interface應高內聚
hatelove提到:
介面隔離原則,與單一職責原則和最少知識原則有一點關係,而SOLID原則的總
建議您另開一系列文,來把您的好觀念闡述給普羅大眾瞭解一下,
相信會對大家更有幫助的,期待您的分享。
屆時我也會過去仔細的學習一番...
在您總是覺得我寫的不夠清楚、簡單明瞭的同時,我也接到一間紐約的公司邀請我去當ASP.NET的講師,所以您的意見跟指教我會好好的記錄下來,用來調整未來我去training的方向。
補充一下,該公司的網址:http://www.netcominfo.com/
Eugenia Bachaleda
Training Manager
Netcom Information Technology
20 West 33rd Street, 4th Floor
New York, NY 10001
Between 5th & Broadway
Main: 646-747-5403
Fax: (646) 356-7052
Web: www.netcominfo.com
To 91:
一個人嘴不嘴砲, 看他是搞懂才回, 還是不懂就回!
(1)某人也在我講兩個Form傳遞參考的文上回了一個"叫我去研究DataBiding", 參考都沒傳過去是要Bi你XX的OO ?
(2) 或者隨口告訴別人『 做DataBinding.他的來源物件好像要實作IDataBinding介面.』真不知道IDataBinding Interface是哪發明出來的 ?
以上, 就知道他的程度實在不怎麼樣, 請他寫個兩篇技術也推拖拉的, 就不用再鳥他了.
所以下一堂會講Liskov substitution principle了?
看情況耶...Liskov substitution principle需要蠻多code的輔助。
怕被卡5000字限制,另外就是還需要找比較好懂的case來做說明。
原本沒有打算把SOLID原則都攤開來講,只是沒想到一發不可收拾。
因為這樣30天會講不完後面要介紹的東西。
哈哈,沒關係啦。有人介紹這些就很高興了
嗯嗯?還是會介紹DIP?
應該會先介紹DIP :)
hatelove提到:
怕被卡5000字限制
不要怕這個限制,
把程式碼貼到 gist 裡,
就避開了這問題了。
XD
之前也有人建議我可以拆成兩篇,或是放到外部引用。
只是感覺有一丁點美中不足,不過很謝謝twtw 您的建議唷。
I will try it, thanks.
常用github的人大概都會用gist...
我因為常混噗浪,所以比較常用:http://paste.plurk.com/