一個列印軟體，由于沒有檔案，理解起來費勁，又挺著急。分為主界面和列印預覽界面，現在兩個界面右鍵彈出選單是一樣的，要求抽出一個類用一套代碼來實作。那么問題來了，如何讓他們共用一套代碼，如何讓他們訊息回應在一起實作？多謝高手指教!
uj5u.com熱心網友回復：
查看兩個界面的右鍵處理函式uj5u.com熱心網友回復：
兩個界面現在是兩套代碼，雖然都是呼叫一些共用的介面，領導的意思是抽出一個類共用，形成一套代碼，我沒太明白他的意思，現在兩個界面右鍵彈出選單的資源ID都是一樣的，難道是讓他們在一個類里面共同回應一套回應函式？uj5u.com熱心網友回復：
請牢記：源代碼本身的書寫是否結構化或面向物件或符合設計模式或敏捷…并不重要，重要的是你是否使用結構化或面向物件或符合設計模式或敏捷…的方法命名識別符號、閱讀、修改、檢查、測驗源代碼。意思是你程式結構看上去再合理，再簡潔，也不一定比看上去一團亂麻的程式結構在運行或修改時更不易出錯，更方便修改，出錯了更容易找到哪里出錯和具體出錯的原因，更容易改正錯誤。
試對比
圖書館（對圖書的分類夠結構化了吧）
和
搜索引擎（可看作是扁平化任何結構資料，僅支持全文檢索）
哪個處理資訊更方便、更高效。
所以
與其費勁去重構代碼讓其看上去更簡潔、更合理
不如費勁學習grep、sed、awk、……這類全文搜索和批處理編輯的工具。
結構越復雜，越難修改，越難除錯。
有時（甚至大多數時候），看上去越合理、越簡潔的代碼，運行起來性能越差，出錯時查找原因越難，找到出錯原因后改正越費勁。
程式員要做的不是盡力避免錯誤，而是聚焦在快速發現并改正錯誤。真正以快速方式輕易解決錯誤，“快速的失敗”遠勝過“預防錯誤”。Fred George
前微軟C#編輯器的開發主管Jay Bazuzi列出的一些有助于找到正確方向的問題；他覺得前同事們應該用這些問題來問自己；實際上不管在哪里作業的開發者們都應該經常問問自己這些問題：
◆“要保證這個問題不會再出現，我該怎么做？”
◆“要想少出些Bug，我該怎么做？”
◆“要保證Bug容易被修復，我該怎么做？”
◆“要保持對變化的快速回應，我該怎么做？”
◆“要保證我的軟體的運行速度，我該怎么做？”
如果大多數團隊都能不時問一下自己，必定會從中得益，因為這些都是真正強而有力的問題。
uj5u.com熱心網友回復：
預覽和列印主要代碼沒有太大差別，都是在dc上畫圖，只是一個dc的螢屏，一個是列印機，由于列印機是一頁頁列印的，而螢屏只有一個，因此控制方面會有所差別
uj5u.com熱心網友回復：
是不是可以寫一個右鍵選單的類呢專門實作這個右鍵選單
如果需要在這個類初始化的時候可以標記一下是在列印界面還是列印預覽界面
uj5u.com熱心網友回復：
主界面和預覽界面都從一個類繼承，試試轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/108138.html
標籤：界面