比如我現在在學習控制元件，做一些按鈕，文本和布局，我想在做專案時直接可以呼叫而不是又重新進行學習和敲代碼，組長說可以把這些東西做成類，具體該怎么做呢?
我現在想把qt的所有控制元件都簡單的做到一個我可以呼叫的類，可以實作嗎？
uj5u.com熱心網友回復：
請牢記：源代碼本身的書寫是否結構化或面向物件或符合設計模式或敏捷…并不重要，重要的是你是否使用結構化或面向物件或符合設計模式或敏捷…的方法命名識別符號、閱讀、修改、檢查、測驗源代碼。意思是你程式結構看上去再合理，再簡潔，也不一定比看上去一團亂麻的程式結構在運行或修改時更不易出錯，更方便修改，出錯了更容易找到哪里出錯和具體出錯的原因，更容易改正錯誤。
試對比
圖書館（對圖書的分類夠結構化了吧）
和
搜索引擎（可看作是扁平化任何結構資料，僅支持全文檢索）
哪個處理資訊更方便、更高效。
所以
與其費勁去重構代碼讓其看上去更簡潔、更合理
不如費勁學習grep、sed、awk、……這類全文搜索和批處理編輯的工具。
結構越復雜，越難修改，越難除錯。
有時（甚至大多數時候），看上去越合理、越簡潔的代碼，運行起來性能越差，出錯時查找原因越難，找到出錯原因后改正越費勁。
程式員要做的不是盡力避免錯誤，而是聚焦在快速發現并改正錯誤。真正以快速方式輕易解決錯誤，“快速的失敗”遠勝過“預防錯誤”。Fred George
前微軟C#編輯器的開發主管Jay Bazuzi列出的一些有助于找到正確方向的問題；他覺得前同事們應該用這些問題來問自己；實際上不管在哪里作業的開發者們都應該經常問問自己這些問題：
◆“要保證這個問題不會再出現，我該怎么做？”
◆“要想少出些Bug，我該怎么做？”
◆“要保證Bug容易被修復，我該怎么做？”
◆“要保持對變化的快速回應，我該怎么做？”
◆“要保證我的軟體的運行速度，我該怎么做？”
如果大多數團隊都能不時問一下自己，必定會從中得益，因為這些都是真正強而有力的問題。
uj5u.com熱心網友回復：
...難道你現在自己做的控制元件不是一個類？uj5u.com熱心網友回復：
1.設計時一定要自上而下。這一點一定一定要做到【具體考慮：自己準備實作的這個模塊的提供哪些功能？提供哪些輸出？達成功能需要哪些輸入？】【考慮這些的時候不要不能去考慮具體代碼如何如何】2.設計模塊時腦子里有且僅有這一個模塊。不要去考慮如何與其它模塊的輸入輸出進行對接。設計的[color=#0000FF]模快的輸入輸出介面不受要外部干擾[/color]
3.模塊功能越單一、越簡單越好！！！模塊功能越單一、越簡單越好！！！模塊功能越單一、越簡單越好！！！
...其它，暫時想不起
然后設計出一大堆獨立、功能單一的模塊。這里大多是抽象的、不面向應用的
接著就是針對具體需求、情景設計一個框架【類似汽車底盤】，把各個模塊連接【這個連接的程序由于模塊設計時對輸入輸出介面高度的獨立性原則，理論上極有可能遇到介面與實際需求介面不匹配的情況，所以，這個連接程序個人以為也是一種連接模塊【具體最常見的表現就是類中屬性的get和set函式】】起來。
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/283234.html
標籤：C++ 語言