許是我孤陋寡聞吧,我知道Java是面向對象思想的,我也知道Web項目很多都採用MVC架構以及三層架構什麼的……
但是,這架構本身與面向對象思想是相背離的!
面向對象思想絕不是"調用任何方法前都要使用對象打點的形式",而是"充分的抽象、利用多態的方式重用代碼"
然而在進入到實際工作中我發現,在經典的架構上使用面向對象思想幾乎是不可能的。
第一,快速。
不是指的代碼運行速度上的快速,而是指開發速度。項目剛開始的時候總是時間緊迫,要快速開發,需求什麼的當然有,也都會把工作做好,可是真正投入到工作中之前,誰都不會明白真正的需求是什麼。
爲了快速開發,Spring自動裝載的時候,我們只會去裝載一個impl,不會嘗試裝載多個,甚至沒機會去編寫另一個impl作爲傳說中的"候補方案"
這當然有它的好處,畢竟直線邏輯是我們所有人都最容易理解的,這樣直線寫下來,比一層套一層的接口+實現更容易理解
而作爲代價,當業務發生擴展時,我們只能在原來的代碼上修修補補,很快就出現了一層又一層的if……這時候再轉,你們都懂得,重構是怎樣一個可怕的工作——尤其是這並非局部的重構,而是整個項目的重構。
第二,框架。
依據分層原理,一層和數據庫打交道,我沒記錯的話它叫DAO,一層處理業務邏輯,叫Service,一層和頁面打交道,叫Action
其中Service層要處理大量的業務邏輯,面向對象想要重載的話,就得從Action中調用各種不同的Service實現
然而,Action是單例的,它只應當Autowired一個Service,這就失去了面向對象的意義
或許"候補方案"的意義仍然存在吧,但我認爲這實在不如從SVN上拉個分支出去
想要解決這個問題,這是架構上的問題,就得從架構上解決。
爲了快速開發,前期的代碼邏輯必然是直線結構,只有當業務出現分支時纔開始變複雜
這樣,框架就得將"不同的Service實現"這玩意隱藏在框架內部
我知道Spring的Autowire可以擇定某一個特定的實現,但我卻沒想清除該如何將這個功能與面向對象思想聯繫起來
總之,在Action中Autowire同一個Service的不同實現這樣的做法簡直不可理喻
依然在想,嗯……想清楚了再說。