分類彙整: 軟體開發

一般來說，程式可以寫成一連串或是巢狀的 if 敍述，那就代表程式流程可以用狀態變數來表示，也就是可以表示成有限狀態機的形式，可以用 interpreter 或是 state pattern 來解決甚至是用表格檢索的方式來表現。但我們一般都不會遇到需要那麼複雜的情況，主要是因為那是框架需要解決的問題，比如說程式語言的 Compiler 或是如 Hibernate 的 HQL、JPA 的 JPQL。 對其它我們會碰到沒那麼複雜的情況，同人的經驗顯示有二種不同解決方式：第一種就是上一篇流程元件化提到的應用 builder pattern 或是更早提到訊息拆解組合應用 visitor pattern，建立一個解決問題過程的 context 脈絡，把答案組合出來，有時候問題比較簡單時，也可能只需要像本篇文章提到只需要應用 strategy pattern 就可以了、另一種方式則是利用泛函編程的高階函式，建構出解決問題的表示式，然後再讓函式一層層套疊的方式來求解，同人不久前分享的語言整合查詢就是這種解法的代表。 閱讀全文 →

從以上以延遲運算實現流程模組化讓我們看到，這個設計樣式和同人先前分享過的語言整合查詢有一些不一樣的地方。語言整合查詢是運用表示式的套疊運算的原理；而這個設計則是引用 Context 的概念，讓各個流程模組元件可以存取並分享處理過程中的資料變化，並且運用 Exception Handler 的機制，來達到流程控制的一致性。 閱讀全文 →

語言整合查詢（LINQ）是非常有用的設計概念，它扭轉我們過去用指令式編程的習慣， … 閱讀全文 →

用以上這樣的模式來重構 legacy code，程式的意圖會很清楚地浮現出來，也會直接具體地關連到問題領域業務邏輯的語言，而不是一大串的 if-then-else 或是 for 迴圈的語法，這有助於不同觀點的相互溝通。你可以從主要流程中具體明白程式在做什麼，而如果需要瞭解實作的細節，則可以進一步去參考那些很簡單的物件化之小函式。由於不同關切點的分離，程式變得更簡單而且容易測試，對後續的程式維護甚至想要增加功能的需求來說，都會得到莫大的助益呀。 閱讀全文 →

最近同人就碰到一個實例，讓我體會到以泛函編程（FP）典範增進功能的可測性。其實，以前遠在美國的 Perter Ho 就曾向包括同人在內的幾位點空間的朋友，分享過相同的觀念，而同人則是藉由最近的實例而對這樣的觀念有更深刻的體驗。 閱讀全文 →

從〈查詢的宣告式語意〉提到的實作中，我們可以發現有關資料搜尋的一種設計抽象概念，可以用相同的模式應用在不同的資料結構上，例如從 XML 文件中搜尋特定的資料節點。同人曾經用過宣告式語意實作轉換期貨交易 Span 檔案，將 XML 資料格式轉換成某種特定格式的資料檔案，程式碼的寫法比傳統的命令式語意寫法更為精簡而直覺。 閱讀全文 →

本來第二篇打算要寫剖析命令列的宣告式語意，不過同人覺得我原先的設計還不夠好，於是就暫時先把它擱置下來。結果一擱就擱了好久，慢慢地也讓我覺得沒有必要重新實作命令剖析列的宣告式語意，因為畢竟會使用到的機會並不多。其實命令列剖析的宣告式語意和前一篇文章的設計原理應該是一致的，因此同人後來決定要跳過它。剛好近看到有朋友討論相關的議題，激發我完成系列文章的動力，這一篇所要探討的主題正是有關於查詢的宣告式語意。 閱讀全文 →

其實以管轄區域分析樣式所發展的資料模型，並不會與資料驅動編程的概念圖相去太多，比較大的差別只在於是否考慮多對多關連的情況。然而經過領域概念分析的過程的好處是，讓我們可以用概念性的表達來略除許多不必要的繁複細節，展現出抽象思考的力量。當然它很困難，但它卻是做好系統分析不可或缺的能力，是值得投注心力學習的技能。 閱讀全文 →