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

軟體重用困難的原因有很多（技術的和非技術的），特別是在擁有大量遺留軟體和開發人員的公司中。我們最常看到的原因之一——也是最容易糾正的原因之一——是未能將業務邏輯與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中。測試可能是必要的，如果可以的話，我們會推遲，但當我們可以執行測試來驗證我們的更改沒有破壞任何東西時，我們總是感覺更好。