前兩天簡單實現了一個Delphi下的MVC模式，沒想到真的就遇到問題了，想想就在不久前和人爭論用不用MVC的時候還暗自認為遇到麻煩是功力不夠的表現，呵呵，汗啊，報應來得真快。
其實說起來都不是什麼大問題，先是重復觸發更新的問題。TA有3個屬性，每個改動都會Change，TB裡包含2個屬性，每個改動都會它更新內部的一個TA的3個屬性，結果我在外面一次改了TB的兩個屬性，Change了6次。這個通過在外面增加關閉觸發和打開觸發的接口來避免。不過，這樣一來觸發機制對用戶不透明了。
還有反復更新不需要更新的界面，其實這個是懶的原因了，當時沒把Change事件細分，不說也罷。此外還有刷新太慢導致速度變慢的問題，現在用一個專用的線程來調用監聽事件了。
還有今天發現的有些重繪的函數引發了Model的Change，結果死循環。這個是本來邏輯就有問題，那個change可以避免，另一方面應該在事件處理的時候避免再次響應這個觸發。
事實上都是小問題，但是一旦積累起來，就有可能讓整個結構不能運行。似乎現在還沒有比較成套的方法來系統的避免。記得好像前一段看過一個JAVA中的反模式的文章，裡面有不少是關於性能的。這樣也就能理解很多Java程序性能不佳的問題了，其實未必是語言的局限，更多的是從結構視角來看設計往往會忽略性能的方面。也就是目前的設計方法保證了概念（對象）的邏輯完整性，卻沒有對協作方式有一個全局的實體。需要程序員通過經驗來自己避免。
此外今天真的遇到一個性能問題，從客戶方看來是一個100×100的時間復雜度，一般並不會出現問題，但是因為服務方都是采用引用方式每次計算的，而這個計算是100的時間復雜度（其實不止，每個100一次中還有5至7次的調用深度），結果這個時間復雜度就有點大了。好像循環深度3是一個坎。
和前面的問題類似，對象分隔使得各邏輯部分在結構上相互獨立性增加，在減少每個部分的復雜度的同時，卻無意中掩蓋了一些整體系統運行的信息，雖然只要是有一定的水平的開發人員都可以避免和改善這種問題。但是首先它確實是容易出問題的，此外，一般的解決方法都會增加開銷或者復雜度，甚至在誤用的情況下不能增進性能反倒成立性能的瓶頸，最後，性能問題也往往成為一下老式程序員拒絕面向對象的一個原因。
感覺這個問題就像C中的指針操作，雖然理論上可以很好的使用，但是沒有足夠的經驗和技巧和細心往往就會出錯。最終這個問題應該又編程語言或框架體構一個完整的解決方案。
目前我還沒有對這個部分進行優化，部分原因是覺得還沒有到完全不能忍受的地步（不過快了），此外覺得還沒有完全分析清楚性能問題的原因。應該去找一個性能診斷的工具來了。
