Posted on 2007-12-03 23:54
canonical 閱讀(1163)
評論(2) 編輯 收藏 所屬分類:
設計理論
我習慣于概念層的推演，而且所闡述的東西多數是我們創造過程中的副產品，與業內常見的觀念實際上是有著很大差異的。有些人感覺我的文章讀不明白是因為沒有采用類似的視角，或者還沒有獨立思考過很多問題。如果只是從業內已經熟知的概念出發試圖理解我所寫的內容，顯然是不可能的事情。所以我常說know something already known.
如果在編制一個新的應用，存在大量代碼可能是
myFunc(){
for each x in set
doSomethingValuable(x);
return packedResult;
}
myOtherFunc(packedResult){
for each y in pakedResult
doSomethingOther(y)
}
其實我們真正關心的是循環內部的某個過程，但是我們經常可以觀察到它們被某些通用的或者特定的循環（集合遍歷）操作所包圍著。Witrix的設計方式是強調業務關注點，而把所有的匯總操作盡量抽象完成。比如現在界面上顯示一些字段。從抽象的操作上說
for each field in dsMeta.viewableFields
show field.viewer
這一過程在平臺代碼中實現，它是一個通用的集合操作過程。不同的具體應用只是關心具體字段的展現形式，雖然我們必然需要字段集合，但是它不是我們注意力的重心。
如果考慮到字段在界面上展示有一個布局問題，我們所要修改的是集合內部的結構方式：
某種結構循環方式（dsMeta.字段組成的布局集合）
show field.viewer
抽離出集合，實際上是在最大限度上分離結構問題和內容問題。
結構是可抽象的，是具有獨立意義的。這就是Witrix所提出的面向結構的設計視角。不是強調對象的所謂業務含義，不是強調某種通用語言（例如ruby）的靈活的語法結構。在這之間存在著厚重的具有物理意義的可以進行結構分析的技術層。
http://canonical.javaeye.com/blog/60758 http://canonical.javaeye.com/blog/126467