「Design pattern」V.S「基礎觀念 & 足夠的思考」

最近回了 Mud 玩玩，碰到那時代的老朋友們，Passerby (鹿)也在其中。 
碰到了鹿，當然免不了又被牠電的亂七八糟。
不過，聊了一下卻發現到。原來，很多的東西我都會，只是....我不知道它的 Termed .. 冏 ..

說實在的，一直以來，我就不是一個很講究 termed (術語)的人。
一來也是因為我英文很破，很多 termed 都是英文比較好講，
二來則是我也不是什麼理論派的人，書看的也沒比人家多。
但最近卻開始慢慢了解到 termed 的重要性。
最後，居然連鹿都跟我們家老大講一樣的話。
基本上，大意就是，假設你的 termed 不精確，則你在和別人討論事情時便需要浪費多餘的時間去解釋，這對許多情況下，都是一種很不必要的浪費。而且，在講解事項時，也還需要另外解釋半天，更是沒有效率。
所以，我也認命的接受這個說法，開始努力的惡補我的 termed ..
然後，也很合理的又被鹿貫頂了一晚，學了幾個滿有意思的 termed：
delegate 委派
aggregation 聚合
composition 合成
另外還有 strategy pattern
*******************  以下是鹿的解釋  **********************
實際上 strategy 是被用來達成 open-closed principle ㄉ原則
你要擴充新功能  只要寫新ㄉ code 實作現有ㄉ strategy class
以及下面這三個....
*********************  又是鹿的例舉  **********************
design pattern 裡有三種常見ㄉ factory
simple factory, factory method, abstract factory
最後搞了半天，我卻突然發現，原來我平常寫 code 的習慣，正好符合所謂的design pattern 中的 simple factory ...
然後 delegate 則也是我經常在定義 OO interface 中不自覺的使用...
而 aggregation 和 stragegy pattern 更是我平常最常使用的 OO 物件模型的架構。
我是一個完全沒有學習過所謂 design pattern 的人，我有的，只不過就是 OOP 的設計理念和基礎。
仔細想想，只能說，理論的產生，畢竟還是因為有實際的需求，才會被提出來。
而 pattern 更只是提出常用的、優良的設計方式。

在許多的情況下，沒學過 design pattern 並不就代表什麼。
假設你對 OO 有了很正確的了解及深入的思考，這些 pattern 則就會自然而然的被你給應用出來。
畢竟是先有 OO 才有人去歸納出這些 pattern 的，不是嗎？
但也不代表讀那些書就不重要，就像我先前所講的，你能用一個 termed 來描述你的設計方式，那當然勝過你還要展示你的 code 來讓人家了解你的設計方式來的有利。
所以，我的結論還是，書雖然要看，但正確的基礎認知卻比任何 pattern 更加重要。
假如能對 OO 有正確的了解認知，則許多東西你便能很容易便吸引進去，反之，看再多的 pattern 也只是只知其然，而不知其所以然，而我則非常不認同這種學習的態度。
至少，這對我來講是非常痛苦的。
講到這裡，有空再來講上面我所學到的那些 termed 的定義吧。
晚安。