l

2016年3月11日 星期五

術語的善與惡

March 10 16:30~17:12

螢幕截圖 2016-03-10 17.10.35

 

有朋友跟Teddy討論design pattern(設計模式),提出他對於學習design pattern的看法:

朋友:我覺得不需要特別去學GoF的那23個設計模式,因為它們都是物件導向設計的整理。只要把物件導向設計的基礎功力打好,自然就可以推導出這些模式,不需要去記它們啊。

從某個角度來看,這種說法也沒錯。但是,這種學習方法衍生兩個問題:

  • 要花多少時間,才可以變成「物件導向技術很好的人」?
  • 在完全不了解GoF設計模式的情況下,一個好不容易成為「物件導向技術很好的人」,要再花多少時間才可以靠自己的力量「重新發現」GoF的設計模式?

給你0~9這十個阿拉伯數字,和+-*/符號,也不是每個人都跟「高斯」一樣,可以推導出梯形公式,不是嗎?

***

Teddy並不是說只要學設計模式,不用管物件導向基礎的知識,而是這兩者應該是相輔相成。學習的過程是迭代式,而非瀑布式。也就是說,學了一點物件導向基礎知識,然後具備學習某些設計模式的基礎;學了設計模式之後,回頭又加深自己對物件導向技術的能力,兩者理應相輔相成。

設計模式是一種術語,重構(refactoring)也是一種術語。術語是一種domain specific language,對於同一個領域的人,用術語溝通可以增加效率,減少誤會。但對於領域外的人而言,術語反而形成溝通阻礙。但這並不表示術語本身是不好的,要看應用情境。

如果你是專業的開發人員,而且你溝通的對象也是同領域的專業開發人員,用術語溝通應該是很正常的情況。如果溝通的對象是非專業人員,則需要用一般人聽得懂的方式與對方解釋。

討論設計情境一:這裡要套用Facade模式來隔離子系統(講完收工)。

討論設計情境二:這裡要用一個class把這個子系統包裝起來,然後透過它提供對外的介面。你先看看客戶端如何使用這個子系統,然後再幫這個class開合適的介面給客戶端。寫好之後把所有客戶端直接存取子系統的程式全部改成透過這個class來存取。

***

當然,每門每派都有自己喜歡的術語,也有很多人喜歡創造術語。術語的氾濫本身,則是另外一個議題了。

***

友藏內心獨白:總不能都用0和1來溝通吧。

1 則留言: