被人隨意問了一句,為何每個service層都要寫一個接口呢,多麻煩~雖然想說點什麼,但是又不知道從何說起,只好從新整理一下思緒.
情景1:在開源框架中有很多這種情況,就是某個功能支持用戶自定義擴展.說白了,它提供了一個接口,我們只需要實現這個接口,把我們自己的實現邏輯補上,就可以讓框架按照我們的邏輯來執行.問題來了,框架的作者並不知道我們的實現類是什麼,如果不定義一個接口,那麼要如何在框架中調用我們的實現類呢?
情景2:我和同事分別做項目的2個不同功能模塊,但是同事的功能中卻需要調用我這頭實現的部分邏輯.為了讓他有一個"占位符"可用,我是不是應該快速的寫個接口扔給他呢?
情景3:一個適配器功能,或是說一個簡單的工廠類,如果沒有定義接口,那麼面對眾多實現類,要如何統一操作呢?
情景4:想讓項目的代碼符合某種"規范",但是又不可能看著別人寫代碼吧,那好辦,先出一套接口,然後你們就看著辦~
情景5:java中沒有多繼承,但是可以多實現接口,那麼就有一件很有趣的事情了,一個實現類可以實現多個接口,然後此時接口可以有選擇的暴露實現類的部分方法,做到"窄化"實現類功能的目的.
當然例子還有很多..這些情況其實可以說是接口好處的體現,所以java有面向接口編程的建議.但是說回Service層一定要有接口嗎?那到未必,因為說到底,多一個接口僅僅是擴展性和某些情況下有優勢,但是是否會用到接口的便利性,不確定的情況下我們未必一定要為"可能"買單.只是多寫那幾行代碼,付出一點就可能避免"未來"的大"麻煩",何樂而不為!?