2013/03/22

Design Patterns @ Oxford

Jeremy 這週為系上的 software engineering programme 開一門 design patterns, 到開課前幾天才驚覺他忘了找助教,寄信給他三個學生討救兵。(或許該澄清一下:Jeremy 找我們純粹是想先找熟人,不是拗學生幫他工作 — 信裡特別說這不是我們的義務。這和我常聽到的師生關係相當不一樣。)我很有興趣聽 Jeremy 如何教這門課(而且報酬出奇優渥⋯),於是接下任務。Software engineering programme 是在職碩士班,每一門課都是一週的密集課程,週一到週四朝九晚五、週五到中午(Kellogg 學院每天供應午餐)。課程型式如同 Oxford 其他課程,講課和上機實習緊密交錯,比方說 design patterns 這門課的主要型式是 Jeremy 每講一兩個 patterns 學生就立刻上機做關於這幾個 patterns 的習題 — 我的任務是解決他們上機遇到的一切疑難雜症。

這五天講了十三個 GoF patterns,實習用的是一個簡單的繪圖程式,以 patterns 重構不良設計或加入新功能。以一般標準衡量,Jeremy 的課程設計和實際執行均屬一流:對每個 pattern 欲解決的問題(具體情境與抽象描述)、標準解法與各種變形、利弊和交互作用等,Jeremy 都給了詳細清楚的說明。實習題目絕大部份是有意義的重構(不會覺得是為了練習而硬套 patterns),各種難度的題目都有,所以進度快的人不會沒事做,進度慢的人可以從容把基本題做好。我相信學生都很滿意。

我就比較失望,因為聽到的東西和我六年前逃離的無甚差別。(不過我不會怪 Jeremy — 改良這種材料完全算是科研題目。)我當年逃離的是「本質上無法精確描述的方法」以及「難以控制的複雜語意」。才聽到第一個 Observer pattern, 當 Jeremy 搬出 sequence diagram 講解通知機制的運作流程時,我心中(的 Dijkstra?)就已不斷吶喊,如果到這個抽象層級還需要仰賴這麼低階的操作語意才講得清楚,情況真的是很糟糕。隨著 patterns 累積,程式行為急劇趨向複雜,協調這些 patterns 時,程式員所擁有最可靠的工具卻仍然是他們的直覺,仰賴的仍然是最原始的運行語意 (operational semantics),程式不亂才怪。(或許 aspect-oriented programming 能幫點忙?不過我猜這仍是 ad hoc 的解法。)換句話說,patterns 沒有具體型式可供組合,也沒有精確刻劃讓人能在套用 patterns 之後方便推論程式性質,只能算是用來訓練程式員直覺的讀物,但我們真的還需要比直覺更好的東西。(換成 Dijkstra 會說「我們需要的是比直覺更好的東西」,不過我不認為我們有辦法丟掉直覺。)

Patterns 有個特徵倒是值得追求的:問題導向。任何 pattern 都從問題描述開始,之後才提出解法。我們需要更多這種把問題轉成解法的方法,而不只是一堆不知如何和問題連結的工具。最後是廣告時間:我和 Jeremy 剛投到 ICFP'13 的論文〈Relational algebraic ornaments〉正是企圖把 inductive families 這項工具透過 relational program derivation 連結到更多問題!

--
Dijkstra 不知何時才能瞑目 XD。