系统地开发高质量的可重用软件组件和框架传统上是一项艰巨的任务。许多嵌入式开发人员成功地将一个程序的代码片段复用到另一个程序中，节省了一定的开发时间;然而，与利用诸如架构、组件和框架之类的资产相比，这种实践做得很少。

　　软件重用困难的原因有很多(技术的和非技术的),特别是在拥有大量遗留软件和开发人员的公司中。我们最常看到的原因之一——也是最容易纠正的原因之一——是未能将业务逻辑与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中。测试可能是必要的，如果可以的话，我们会推迟，但当我们可以运行测试来验证我们的更改没有破坏任何东西时，我们总是感觉更好。