系統地開發高質量的可重用軟件組件和框架傳統上是一項艱巨的任務。許多嵌入式開發人員成功地將一個程序的代碼片段復用到另一個程序中，節省了一定的開發時間;然而，與利用諸如架構、組件和框架之類的資產相比，這種實踐做得很少。

　　軟件重用困難的原因有很多(技術的和非技術的),特別是在擁有大量遺留軟件和開發人員的公司中。我們最常看到的原因之一——也是最容易糾正的原因之一——是未能將業務邏輯與UI(用戶界面)分開。將業務邏輯和UI代碼交織在一起的項目轉換成新的屏幕尺寸、硬件平臺或操作系統既耗時又乏味——這是一個常見的需求。

　　如果你正在構建具有嵌入式GUI(圖形用戶界面)的產品，并且希望以系統的方式利用代碼重用，那么你需要采取四個步驟。

　　步驟1—分離業務和UI邏輯

　　換句話說，在嵌入式開發中，讓嵌入式GUI專注于它的角色：呈現信息和與用戶交互。應用程序的大腦(也稱為后端)——系統交互、計算和算法以及特定領域的知識——需要完全脫離UI。由于在將軟件移動到不同的產品或平臺時，幾乎可以保證GUI會發生變化，因此，將業務和UI邏輯解耦可以讓你輕松“砍掉頂部”，創建依賴于經過測試的組件的新外觀或新行為。

　　為了保護后端業務邏輯不受所有這些混亂的影響，并使其盡可能可重用，請實現客戶機-服務器模型、模型-視圖控制器或任何其他最適合你和你的團隊的范例。

　　第2步—使用正確的膠水

　　雖然你希望業務邏輯和UI是完全獨立的組件，但它們需要能夠進行通信。你需要通過可配置的事件系統、腳本環境或編程API將兩者“粘合”在一起，從而將UI松散地耦合到后端。膠水接收來自后端的信息，并使用它填充用戶控件，同時還將用戶操作傳遞到后端。

　　在嵌入式開發中，如果膠水的連接機制太弱，你將被迫在更強大的后端軟件中實現一些UI邏輯，而這恰恰是不應該的。類似地，如果粘合環境太強，那么可能會在UI環境本身中實現部分業務邏輯。這通常不是故意的，但邏輯代碼潛入UI層是后端和GUI共享相同語言的框架中的常見問題。你需要一種恰到好處的膠水——足夠強大，可以完成工作，但它可以很容易地避免意外實現業務邏輯。

　　第3步—創建API合同

　　為了實現組件的干凈分離，你需要一個API契約。API合同是一種文檔，它可以保證一段代碼在接收到某些輸入時所做的事情。該合同提供了對調用者和被調用者的責任的共同理解，并允許調用者依賴模塊內函數的結果——不多不少。

　　第4步—強制執行API合同

　　為了確保API契約有效，嵌入式開發人員需要創建測試。正確設計的測試套件可確保軟件正常工作。它可以幫助你隔離問題，以發現它們是否在應用程序邏輯或UI中。測試可能是必要的，如果可以的話，我們會推遲，但當我們可以運行測試來驗證我們的更改沒有破壞任何東西時，我們總是感覺更好。