管理軟體的複雜度和變化.
當你確信你的設計中有乙個問題需要解決的時候,或者當你確信未來的需求可能會改變時,都可以採用模式.然而模式可能帶來複雜性,如果沒有必要,我們絕不需要這樣的複雜性.
1.應該保持簡單, 在實際的開發中, 目的是以簡單的方式解決某個問題, 而為了模式而模式, 這樣只會讓系統更加複雜.我們應該在有更簡單的辦法的時候果斷採用這個辦法, 以達到既解決問題又不給系統增加任何的複雜度.
2.不要假想任何改變而加入不必要的模式,應該以實際業務為主, 不要去假想著業務將來如何改變, 這同時也要求開發人員能夠熟練的掌握業務.
3.重構, 重構是物件導向開發中非常常見的事情.當我們在重構時,就說明既有設計不夠好,**結構已經比較混亂, 這個時候可以思考設計模式所能帶來的幫助, 這是乙個使用模式很好的時機
4.不要害怕刪除模式, 如果乙個系統足夠複雜, 在有些地方不需要預留彈性而且刪除模式能夠使系統結構趨向於清晰簡單時, 果斷刪除模式.
5.現在不需要, 就別做! 要抗拒」建立漂亮的架構以應對任何方向的改變」這樣的**! 不要假想任何理由去新增乙個設計模式, 這樣只會讓系統越來越複雜
以下為書本原文:
在設計時,盡可能的用最簡單的方式解決問題. 目標應該是簡單而不是」如何在這個問題中應用模式」.千萬不要認為:如果沒有使用某個模式解決某個問題,就不是經驗豐富的開發人員.如果你能夠保持簡單的設計,那麼你將會得到其他開發人員的欣賞和尊敬.正確的說法是,為了讓你的設計簡單且有彈性,有時候使用模式是最好的方法.
當你在設計的時候,如果確定在你的設計中可以利用某個模式解決某個問題,那麼就使用這個模式! 如果有更簡單的解決方案,那麼在決定使用模式之前應該先考慮這個方案.
如何知道何時使用乙個模式,這就需要經驗和知識.一旦你確定乙個簡單的解決方案無法滿足你的需要,應該考慮這個問題以及相關的約束–這可以幫你將問題對應到乙個模式中.如果你對於模式有很深的認知,就可能知道有什麼模式適合這樣的情況.否則,就花時間調查一下可能會解決這個問題的模式,模式類目中的意圖和應用部分會特別有用.一旦找到了乙個看起來適合的模式,要先確定你是否能接受這個模式所帶來的後果,以及對設計其他部分的影響.如果一切看起來都很好, 就用它吧!
有一種情況, 即使有更簡單的解決方案,你仍然想要使用模式,這種情況就是: 你預期系統在未來會發生改變.正如我們所見過的,找出你的設計中會改變的區域,通常這是需要模式的跡象.但是務必要確定一件事:加入模式是要應對可能發生的實際改變,而不是假想的改變.
重構是通過改變你的**來改進它的組織方式的過程.目標是要改善其結構, 而不是行為.這是乙個很好的時機,可以重新檢查你的設計來看看是否能夠利用模式讓他擁有更好的結構.比方說,**內如果充滿了條件語句,這可能意味著需要使用狀態模式,或者意味著,應該利用工廠模式將這些具體的依賴消除掉.
何時應該刪除模式呢?當你的系統變得非常複雜,而且不需要預留任何彈性的時候,就不要使用模式.換句話說,也就是當乙個較簡單的解決方案比使用模式更恰當的時候
設計模式威力很強大,你很容易就可以在當前設計中看到模式的各種應用方式.開發人員天生就熱愛建立漂亮的架構以應對任何方向的改變.
要抗拒這樣的**呀!如果你今天在設計中有實際的需要去支援改變,就放手採用這個模式去處理這個改變吧~然而,如果說理由只是假想的,就不要新增這個模式,因為這只會將你的系統越搞越複雜,而且很可能你永遠都不需要它!
設計模式思考
高層模組不應該依賴於底層模組，應該在他們之間建立乙個抽象層，來實現可替換的底層，不變的介面層。這個是物件導向的更高境界了，面向介面程式設計。上層和下層通過唯一途徑聯絡就是介面，這有點類似與作業系統和軟體和硬體之間的關係，他們的聯絡也是通過能夠接觸到那一層介面來實現。可以說我們只需知道介面就能完成呼叫...
用腳趾頭思考
序言 傳說能寫出沒有bug的程式，就能獲得永生。奈何橋水，彼岸花美。而我不求永生，只為寫下各種bug。風言風語 1 遊蕩三界之中，行勾魂引路之事 每個人都會有乙個主線任務，也有很多分支任務，就在十字路口，這也稱之為選擇。在git中，有各種分支，只有乙個主分支，有功能分支，開發分支，預發布分支。好多好...
企業開發模式思考
何謂企業級開發，企業級開發指針對企業需求的開發方式。一般會有2個任務，乙個是流程的建設和管理，乙個是資料的報送和管理。不管是這兩個任務的哪一種，我都建議不要採取資料庫為中心的操作。因為企業的資料和流程管理需求一般都不是實時的，沒有太高的效能需求，但是變化卻很大。包括資料報送的樣式和顯示的樣式，以及流...