程式架構雜想

最近一直都在嘗試設計對於自己而言一個比較大型的程式，這對我而言算是很充滿挑戰性的事，因為我從來沒有用過正規方法來設計這樣子的一個程式，我一直以來都是且戰且走型，這也難怪我的程式一直都寫不大，不然就是充滿破爛 XD。

庖丁解牛，恢恢乎游刃而有餘。 - 莊子

這大概是我對於設計架構上最大的感想，基本上我還是非常習慣紙筆思考，對我而言，不管是傳統的 OO 設計方式抑或是 eXtreme Programming 的設計方式 (在這幾天終於了解為什麼會叫 eXtreme 了，誤用真的很危險)，事前的分析與設計是一定需要的，如果一開始的需求就是固定不太會變動，其實傳統的 OO 設計方式應該是相當的夠用，重點是，如果在途中一半更改需求的時候該如何因應 ? 這是我這次設計程式不會遇到的問題。我想我可以日後再好好的想想，因為我也不覺得用 XP 會是最佳解。

如果是設計演算法的程式時，其實我覺得算是最好設計的，但是在轉換上的時候，必需對數學的 set 要有一定程度的認知及轉換上的經驗(基本上 set 可以表示任何事情，int 也是一個數學的 set，一個 struct 也是一個 set，只是是一個 set * set ...)，也就是說，如果轉換到一個夠簡單夠容易處理的模型，要設計起來也相對容易的多。但是對於 set 的轉換，其實到目前還是沒有頭緒，以後想到再補述好了。

架構設計的時候，ycma 建議的是 top-down approach，而我自己使用的是 button-up approach，他很堅持我的方法是錯的，會造成寫程式時候的災難，不過我還是蠻堅持先用 button-up run 過一次，再使用 top-down 把所有東西連起來，因為兩種方法的交錯使用，讓我學到很多事，在此在思考，是否只用 top-down approach 就可以解決呢，我不這樣子覺得，這或許也是等到設計完的時候，會有一些有趣的事發生。

設計架構會遇到的三個主要問題，data consistency, unduplicated code, consider function side effect，最後一個其實是最好解決的(拜 Functional Programming 所賜，現在寫程式很想會觀察 code 之間的相依性，把 code 視為一個 block，雖然這不是 FP 的主意，但是我卻是因為這樣子學會的 ... Orz)，data consistency 一開始的設計就很重要，我會嘗試把資料集中放在少數幾個 Class 裡，其他使用 id 存取 (不一定非得用 Pointer or reference，有時候我太執著於用語言的層面來解決這個問題，不過這個問題的確也是還在思考)，而 unduplicated code 是最困難的，因為很容易會有相同的功能，這也不是用個 Generic Type 就可以把這個問題處理的很好，這目前還在思考怎麼辦。

基本上算是雜亂的記錄，希望一個月過後，自己再看到這一篇的時候，能給自己一些解答。

---
如果錯的話，就指正吧，我好久沒有寫技術文了，雖然這篇也稱不上技術文就是了 XD。