寫程式跟做藝術是不一樣的,所以我們在學習並且完成程式的過程中難免都寫過醜陋的程式碼,比起藝術家創造藝術品,寫程式更接近一個工匠製作可用的成品
的過程。
我們都希望自己所創作出來的是藝術品,但現實中迫於時間壓力和自身創作能力或是個人視點的限制,要創作出藝術品並不是那麼容易的。比起創作出藝術品,以現有的能力賺取金錢也是一件很重要的事情,因為在獲取了金錢足夠生活之後,才有時間(金錢)能追求自己的理想,打造出一座藝術品
。
從程式語言誕生至今,撰寫程式碼的方式也出現了各種不同的流派,在這些流派中難免有某些限制和流傳已久的程式思維,這些流派、方法無非是為了讓大家未來寫程式時能夠更加輕鬆而發想出來的。
在軟體工程中, 行為型模式為設計模式的一種類型,用來識別對象之間的常用交流模式並加以實現。如此,可在進行這些交流活動時增強彈性。
-- by wikipedia
行為模式是根據某些常出現的行為交流( behavior communication ),設計出來的模式,在現實生活中會經常碰到類似的行為模式,所以根據這些交流設計出對應的程式模型加以實現,這些被實現的程式碼對應相應的行為,擁有程式擴充、設計上的彈性,因此對於這些固定會出現的幾種模式,大家有了一種固定的寫法···。
定義物件之間的一種一對多的依賴關係,當一個物件發生改變的時候,所有依賴於他的物件都得到通知並被自動更新。
由於資料(流)的處理越來越被重視,最近常聽到的響應式編程(Rx)是其應用之一,應用這種程式思維可以讓程式碼更佳簡短易懂。
定義一個操作的演算法骨架,而將一些步驟延遲到子類別中,反本方法使得子類別可以不改變一個演算法的結構,即可重定義該演算法的某些特定步驟。
減少程式碼的重複。
將一個請求封裝為一個物件,從而使你可用不同的請求對客戶進行參數化,可以對請求排隊或紀錄請求日誌,以及支援可取消的動作。
調用的物件和實現的物件不同,因此可以額外實現各種不同的功能(排列、執行、取消、重做、記錄日誌···等等)。
在一個物件內部狀態的改變,同時改變了他的行為,讓物件看起來似乎修改了他的類別。
代替原本是由if else等判斷子句的程序,經由某個物件改變內部屬性達到改變他行為的目的,所以建立新的子類可以很簡單的新增新的不同的狀態。
使多個物件都在機會處理請求,從而避免請求的發送者和接收者之間的耦合關係。將這些物件連成一條鏈,並沿著這條鏈傳遞該請求,直到有一個物件處理它為止。
可以實作有關於權限的功能。
還有一些沒有提到的行為模式明天再做個最後整理,感謝!
參考資料
-- 大話設計模式
-- Android源碼設計模式解析與實戰
-- Design Patterns in Object Oriented Programming