關於[面向集合的框架設計]的一些說明

我習慣於概念層的推演，而且所闡述的東西多數是我們創造過程中的副產品，與業內常見的觀念實際上是有着很大差異的。感覺不明白是因爲你沒有采用類似的視角，或者還沒有獨立思考過很多問題。如果你只是從業內已經熟知的概念出發試圖理解我所寫的內容，顯然是不可能的事情。所以我常說know something already known.

如果你在編制一個新的應用，存在大量代碼可能是
[code]myFunc(){
for each x in set
doSomethingValuable(x);
return packedResult;
}

myOtherFunc(packedResult){
for each y in pakedResult
doSomethingOther(y)
}[/code]
其實我們真正關心的是循環內部的某個過程，但是我們經常可以觀察到它們被某些通用的或者特定的循環（集合遍歷）操作所包圍着。Witrix的設計方式是強調業務關注點，而把所有的彙總操作儘量抽象完成。比如現在界面上顯示一些字段。從抽象的操作上說
[code] for each field in dsMeta.viewableFields
show field.viewer[/code]
這一過程在平臺代碼中實現，它是一個通用的集合操作過程。不同的具體應用只是關心具體字段的展現形式，雖然我們必然需要字段集合，但是它不是我們注意力的重心。
如果考慮到字段在界面上展示有一個佈局問題，我們所要修改的是集合內部的結構方式：
[code] 某種結構循環方式（dsMeta.字段組成的佈局集合）
show field.viewer[/code]
抽離出集合，實際上是在最大限度上分離結構問題和內容問題。
結構是可抽象的，是具有獨立意義的。這就是Witrix所提出的面向結構的設計視角。不是強調對象的所謂業務含義，不是強調某種通用語言（例如ruby）的靈活的語法結構。在這之間存在着厚重的具有物理意義的可以進行結構分析的技術層。[url]http://canonical.iteye.com/blog/60758 [/url] [url]http://canonical.iteye.com/blog/126467[/url]

stream style就是向流中不斷追加內容，o.put(y).put(z).put(t)這種方式，看一下jQuery的代碼就知道了。

SAX的事件驅動方式結合模式匹配能力確實可以直接在局部應用轉換邏輯，但是缺乏狀態空間的配合，它面對複雜問題時是乏力的。