面向抽象(接口)的編程

當你要設計一個東西的時候,首先考慮的是實體類,也就是傳說中的model,比如User,這個基本上就是Java Bean。

假如你想加一個方法,可以添加一個用戶。這個時候,你不可能在User這個類裏面添加方法,因爲你不可能說爲了調用方法還得先new一個user出來,邏輯上說不過去。最好的方法是你再專門創建一個service類,比如叫做UserService。這個時候當你使用UserService裏面的add(User u)方法的時候,就會通過UserService去操作數據庫。

在更大的項目中,即使這樣都還不行,因爲你可能想要操作多個數據庫,甚至多種數據庫,這個時候就需要在UserService後面再加一個UserDAO。通過它來操作不同類型的數據庫,從而達到屏蔽數據庫的作用。這樣的意思就是,對外提供一個接口,叫做UserService,然後由UserDAO來覆蓋底層的東西,這樣你將來換數據庫,或者平臺移植,就不太需要重寫這些東西,只是添加一些model和service就行了。

ps: DAO=Data Access Object

以後的操作方法就是,你在UserService裏面定義一個UserDAO類型的成員變量。假如UserDAO裏面有一個方法叫做save(User user),負責向數據庫添加一個User的數據,那麼你就在UserService裏面寫一個方法叫做add(User user),在裏面直接調用save(User user)就行了。save(User user)當然就提供了關於數據庫的操作。

但是,問題又出來了,即使你寫了UserDAO,假如裏面實現了MySQL的操作,將來你要換數據庫或者緩寸什麼的,你還得改。這不是一樣麻煩嗎?

於是就有解決方法,那就是說將UserDAO也寫成接口,然後分別創建幾個實現類,比如說MySQL的,比如ORACLE的,將來你在Service裏面,想調用哪個就調用哪個就完了,不會影響任何代碼。就算將來再出了新的東西,也只是增加一個實現類的功夫罷了,完全不影響對外的接口。

可能不見得像現在說的這麼完美,但是在大項目的開發中,這樣做確實可以增加很多靈活性,讓系統代碼更加健壯。說句題外話,其實維護的成本不見得小於開發的成本,一個項目如果最初就能把可維護性考慮進去的話,雖然可能在開發的時候更加繁瑣一些,但是一旦將來需要維護修改了(一定會的),就會省很多時間成本。切記這一點。

記住一個大致的原理就是,如果系統對於訪問有靈活性的要求,那麼最好就寫成接口。

說到這裏,該說說配置文件了。

試想在大項目中,有很多很多的model類,很多很多的service類。有時候你希望你的service類不只有一個功能,那麼最好的方式就是將service寫成接口,然後寫相應的實現類。舉個例子吧,你寫項目的時候總要測試吧,使用的是一樣的功能吧。你不可能爲了測試專門再去寫一套代碼吧。大項目肯定要訪問數據庫的,但是測試的時候不可能也訪問數據庫吧。那麼將service寫成接口,寫一個實際中要使用到的實現類,再寫一個測試用的實現類。實際使用的類該連接數據庫就連接,測試的時候配置一個List就行了。

但是你總是不知道你有多少實現,還有你不知道你要new多少次,假如有一天你決定換一個實現,所有new的東西都必須全部換過,可能成百上千,非常容易出錯。有問題就有對策,那麼你寫在配置文件中就好了。將接口和實現類綁定起來,調用的時候不管它的實現是什麼,儘管調用接口方法就是了。某一天你不想用這個實現了,那麼你只需要在配置文件中修改一行就行了,不管你用了多少次,只有這樣才能保證在大項目的開發過程中修改代碼的效率變高。上面說了這麼多,這個就叫做Spring的注入,也就是Guice的基本原理。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章