Delphi、MFC、WinForm中有沒有類似的東西？
如果沒有，有什么是Qt容易做到而上述三者不易做到的，舉個栗子？
uj5u.com熱心網友回復：
有人了解這個嗎？uj5u.com熱心網友回復：
uj5u.com熱心網友回復：
uj5u.com熱心網友回復：
Qt的圖形架構基于MVC思想設計的，也就是資料與顯示分離，Sense負責事件分發、焦點管理、快速介面等，View負責具體圖元的顯示、布局（縮放、翻轉、影片），而且Qt是一個跨平臺的框架（Window、Linux、QNX、Android、iOS）。uj5u.com熱心網友回復：
好的
uj5u.com熱心網友回復：
請牢記：源代碼本身的書寫是否結構化或面向物件或符合設計模式或敏捷…并不重要，重要的是你是否使用結構化或面向物件或符合設計模式或敏捷…的方法命名識別符號、閱讀、修改、檢查、測驗源代碼。意思是你程式結構看上去再合理，再簡潔，也不一定比看上去一團亂麻的程式結構在運行或修改時更不易出錯，更方便修改，出錯了更容易找到哪里出錯和具體出錯的原因，更容易改正錯誤。
試對比
圖書館（對圖書的分類夠結構化了吧）
和
搜索引擎（可看作是扁平化任何結構資料，僅支持全文檢索）
哪個處理資訊更方便、更高效。
所以
與其費勁去重構代碼讓其看上去更簡潔、更合理
不如費勁學習grep、sed、awk、……這類全文搜索和批處理編輯的工具。
結構越復雜，越難修改，越難除錯。
有時（甚至大多數時候），看上去越合理、越簡潔的代碼，運行起來性能越差，出錯時查找原因越難，找到出錯原因后改正越費勁。
程式員要做的不是盡力避免錯誤，而是聚焦在快速發現并改正錯誤。真正以快速方式輕易解決錯誤，“快速的失敗”遠勝過“預防錯誤”。Fred George
前微軟C#編輯器的開發主管Jay Bazuzi列出的一些有助于找到正確方向的問題；他覺得前同事們應該用這些問題來問自己；實際上不管在哪里作業的開發者們都應該經常問問自己這些問題：
◆“要保證這個問題不會再出現，我該怎么做？”
◆“要想少出些Bug，我該怎么做？”
◆“要保證Bug容易被修復，我該怎么做？”
◆“要保持對變化的快速回應，我該怎么做？”
◆“要保證我的軟體的運行速度，我該怎么做？”
如果大多數團隊都能不時問一下自己，必定會從中得益，因為這些都是真正強而有力的問題。
uj5u.com熱心網友回復：
老趙偶爾百度，偶爾灌水，有含量的不多。uj5u.com熱心網友回復：
uj5u.com熱心網友回復：
uj5u.com熱心網友回復：
lz不搞寶藍那套東西啦？uj5u.com熱心網友回復：
Qt大概了解一下。
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/11093.html
標籤：非技術區
上一篇：funcode顯示問題