Oop 逻辑设计与物理设计

我有一个非常一般的设计问题，但我将用一个例子来具体阐述它

假设您正在为数字打印机开发嵌入式软件。机器有4个打印头（C、M、Y、K颜色各一个）。每个打印头执行相同的任务：取出碳粉并将其放在页面上

在运行时，我们可以用两种不同的方式组织API。我们要么遵循逻辑（也称为“功能”或“过程”）设计，以便客户端软件可以控制所有打印头的打印过程（例如，一次更改所有颜色的亮度）。或者我们遵循物理设计，以便客户端软件可以单独控制每个打印头（例如，仅更改洋红色的亮度）

---

这是软件设计中的一个经典难题：我们要么按活动组织，要么按体系结构组织。通过功能或形式。我的问题是：有没有可靠的标准来选择一个而不是另一个？不同的项目会有不同的选择，根据各自的情况，两者都可能是正确的；所以我不是问哪个最好，而是问如何选择。例如，我对您关于松耦合、可维护性、分层、面向角色的设计、架构设计模式等的想法很感兴趣。

编写一个遵循物理设计的界面。除此之外，您还可以分层使用物理接口的逻辑接口。因此，不要选择什么时候可以两者兼得。

我想这取决于你的客户想要什么——从客户的角度来看，系统的要求

就我个人而言，我倾向于将问题分解为两个较小的部分/问题：

访问和控制物理组件的底层代码—物理API。（这始终需要在您选择的任何设计场景中完成，以便能够集中精力并完成）

使用上述API提供更具功能/流程结构的API（如有必要）

嗯

---

Len

做最简单的事情，以满足项目要求

如果逻辑设计满足项目的要求，那么对逻辑设计和物理设计进行编码可能会引入不必要的开发工作（从而产生成本）