在以前的一片博文裡 我發表了我對設計模式的一點看法
但是今天的乙個案例又讓我對設計模式又有了一點思考
今天在處理這麼乙個問題:
元件a是我以前寫的,這個元件會不斷被重用,而今天要寫到的模組b用到了a,現在b有乙個很奇葩的需求,a似乎滿足不了了!,怎麼辦?!
首先我想到的是能不能把問題簡單化,繞過這個問題
經過仔細的分析後,我的結論是:沒法繞過去,只能硬上了,給a新增功能!
在思考這個這個功能怎麼在a中實現的時候,我發現這裡面的邏輯很複雜,而且很特殊,後來看a**的人一定看不懂為什麼會有這個功能,這個功能也不大可能在以後被用到
其中由於專案進度的關係,專案組讓另乙個同事來處理這個問題,於是我先去幹別的
同事幹完之後,我一看,坑爹了,這位同事沒有理解需求,給a新增了乙個不必要的功能,我果斷又掉進了坑里,還得我來處理這個問題
我又試圖給a新增功能,新增介面...
首先我想給a新增狀態(以前a只有一種狀態),在狀態1下如何如何,狀態2下提供b要的服務,這導致a裡面密布if else,**很難看
這個時候可以考慮用狀態模式了,抽象出各個狀態的區別,放到介面類裡面,各個狀態只要實現介面就好了,看起來很完美
但是! 這個狀態2很難理解,也很難被復用,因為它完全是為了模組b的需求而做的,這個狀態2很有雞肋的感覺
其實可以用策略模式,這種情況下具體行為應該由外部注入,而以後a的使用者根本不會接觸到醜陋的狀態2,只有b知道狀態2(或者應該說是策略2)
以前看設計模式的時候我就不理解策略模式和狀態模式的區別,書上有講,但是語焉不詳,說不到重點
下面整理一下我的理解:
元件a承擔一定的職責,這個職責要處理很多種功能,而這些功能分為兩類,常用的,不常用的
不常用的功能甚至在需求分析的時候都不會被考慮到
常用的功能可以做成狀態模式,那麼元件a的**將會非常清晰,這些**也將是非常穩定的
不常用的功能由於無法預知,應該抽象出介面(這個介面可能具體需求來了才能確定),具體實現由外部注入,保持元件a的簡單
可以想象,如果所有需求都放在元件a中實現,那麼元件a很快就臃腫不堪,無法維護,但是元件a又必須實現那些常見的需求,這些需求可以抽象為狀態,由元件a實現
這其實是乙個職責的問題,可以重用的功能應該放到元件a中,不可以重用但是又依賴於a的職責可以由a提供乙個介面,外部來注入
ps:不得不吐槽一下網上關於設計模式的文章,經常拿什麼矩形正方形(眾所周知這個例子有bug),各種動物(包括很奇葩的寓言),甚至唐僧孫悟空豬八戒(鄙視下閆巨集的那本書,設計模式真的需要這麼大一本書才能講清楚嗎?)做例子,我很懷疑這些東西真的能表現設計模式嗎?
設計模式的一點思考
建立型 builder 當我們要建立的物件很複雜的時候 通常是由很多其他的物件組合而成 我們要將複雜物件的建立過程和這個物件的表示 展示 分離開來，這樣做的好處就是通過一步一步的進行複雜物件的構建，由於在每一步的構造過程中可以引入引數，使得同樣的構建過程可以建立不同的表示。abstractfacto...
關於模板方法和策略模式的一點思考
該隨筆的思想原點，應該算是在兩三年前了。當時和一前同事聊天 不知怎得就聊到了http訪問。一 我記得他和我說過的第一句話，大概是 有沒有已經封裝好的 比較強大的httputil。也可能是受業務的影響 介面對內 我當時接觸到的http訪問，大多比較 規範 至少有乙個介面約束在約定著某些東西，不至於一會...
策略模式的一點自我總結
package cn.zhao.moshi.strategy public inte ce idiscountstrategy package cn.zhao.moshi.strategy 按使用者所買物品單價進行折扣 public class impldiscountbyprice impleme...