close
知識就是力量，當我們面對它，
如果你了解學校學的東西，而沒有使用模式的經驗與實務，
那麼這不會在你的生活中造成多大的差別。
的確，在經過相當程度、對於妥善設計過的程式碼閱讀與維護的洗禮後，
閱讀此書真的超有感覺!! (感謝前公司同事)
閱讀此書真的超有感覺!! (感謝前公司同事)
建議對java有一定程度接觸
(至少繼承、實踐、介面、多型、抽象類別等應該已經了然於胸)
(至少繼承、實踐、介面、多型、抽象類別等應該已經了然於胸)
後再來登上模式的殿堂，不然容易因為翻譯名詞的生澀難懂，而對本書望而卻步!
書中使用大量的圖示 - (包括封面穿著清涼的辣妹^Q^)
我們的腦袋對於視覺有比較高的反應，影像比文字更容易記憶，
可以使得學習更有效率(甚至可以讓知識回想與轉述的效率提升89%)。
可以使得學習更有效率(甚至可以讓知識回想與轉述的效率提升89%)。
來呈現對於各種Design Patterns的描述，有效的增進了閱讀效率，
並提供了視覺化內容帶給讀者的好處!
並提供了視覺化內容帶給讀者的好處!
書中節錄的隻字片語:
我們總是需要花許多時間在系統的維護和更動上，比原先開發花的時間更多
應該致力於提高可維護性和可擴充性上的再利用程度。
被維護系統搞的身心俱疲的工程師可能會說:
很好的觀念，很漂亮的文字啊~ 說比做容易，要如何達到目標呢?
A: 多跟這本書到StarBucks混在一起就對啦!
千萬不要還沒開始思考就一律否定，那只會導致自己依舊裹足不前~
千萬不要還沒開始思考就一律否定，那只會導致自己依舊裹足不前~
建立可維護的ＯＯ系統，要訣就在於隨時想到系統以後可能需要的變化，
現在要如何設計，以因應以後的變化。
可再利用、可擴充、可維護是重點，難度在於想到以後可能需要的變化，
這可能需要仰賴(對此系統)有經驗的SA在系統設計初期的參與，
但是書中也提供了一些技巧讓我們將系統設計得更為彈性。
這可能需要仰賴(對此系統)有經驗的SA在系統設計初期的參與，
但是書中也提供了一些技巧讓我們將系統設計得更為彈性。
藉由動態地合成物件(composition)，可以寫新的程式碼擴充既有的系統，
而無須修改既有系統的程式碼。
既然沒有改變既有的程式碼，現有的程式碼將大幅減少引進bug的機會，
或產生意外的副作用。
或產生意外的副作用。
程式碼應該
如同晚霞中的蓮花一樣地關閉(免於改變)，
如同晨曦般的蓮花一樣地開放(能夠擴充)。 XD
如同晚霞中的蓮花一樣地關閉(免於改變)，
如同晨曦般的蓮花一樣地開放(能夠擴充)。 XD
=> 對修改關閉，對擴充開放
尤其是多人共同開發的系統，這個技巧尤其重要，只要系統便於擴充 -
在不修改既有程式碼的情況下，就可以搭配新的行為
就不需去改舊有的程式
(這可能是別人開發、自己開發、或是別人和另外一人共同開發的)，
(這可能是別人開發、自己開發、或是別人和另外一人共同開發的)，
大大減少牽一髮動全身的可能性!
今天如果新加的元件有問題，針對它來修改即可，縮小了災難可能擴散的機率!
今天如果新加的元件有問題，針對它來修改即可，縮小了災難可能擴散的機率!
認識極少化守則: 只和你的密友談話。
在設計中，不要讓太多類別捆綁在一起，
免得修改系統中一部分，會影響到其他部分。
免得修改系統中一部分，會影響到其他部分。
如果許多類別之間互相依賴，就會變成一個易碎的系統，
需要花許多成本維護，也因為太過於複雜而不容易被了解。
需要花許多成本維護，也因為太過於複雜而不容易被了解。
(雙面刃)
此守則可能會導致更多的[包裝]類別被製造出來，以處理和其他物件的溝通。
此守則可能會導致更多的[包裝]類別被製造出來，以處理和其他物件的溝通。
這可能導致複雜度以及開發時間的增加，並降低執行期的效率。
沒有設計過的系統，一開始為了求快以符合開發時程要求，
把一堆類別五花大綁在一起是非常常見的(直覺、好寫換取時間，省略維護可能問題)
最慘的是維護者另有其人，
在開發者已不可考的情況下打開看到完全沒有註解的source，必定是幹醮連篇!
在開發者已不可考的情況下打開看到完全沒有註解的source，必定是幹醮連篇!
為了讓系統可以走的更長遠，也為自己多做做功德，適當的設計過後再動手，是完全需要的!
最後用書中極紅的鴨子介紹許多模式的攜手合作(複合模式),
再帶出MVC架構(非常值得一讀，讀完可以輕易回答此類面試問題呢!)，
算是在看過使用MVC架構出來的系統之後，回來看到MVC的文字描述，
有種返璞歸真的感覺呢~ XD
總結的部分最重要的觀念還是不要為了用模式而用模式，
找到最簡單有效的解決方法才是王道!
當在過與不及之間找到平衡點，也就差不多晉升模式悟道者的境界了!
有了這些前人歸納實證的漂亮方法，可以說讓編程的世界和明天能夠因此而變得更加美好!
全站熱搜
留言列表
旅行的意義 (7)
