我目前正在设计一个通信系统，希望获得一些有关我的 OOP 方法的建议。
这非常简单 - 它从串行端口获取数据，将数据划分为消息，然后将这些消息解析为其余代码可以使用的内容。例如，消息可能是“LightSensorReport”，其中包含从多个传感器收集的数据；这种情况下的数据只是整数值，但也有数据更复杂的情况。
所以，我认为串口是一个实现流接口(interface)的类。然后，我用于解析流的类负责从该流中取出数据，找出消息边界在哪里，然后将这些消息发送到另一个类，该类将消息的二进制数据转换为“LightSensorReport”等对象。
我的问题来自于对最终数据类及其实际含义的思考 - 在本例中为“LightSensorReport”。对我来说，它不完全是一个对象 - 它只有状态，但它不会对该数据执行任何操作(因此它实际上是一个数据结构)。这是一种气味吗？这适合良好的 OOP 吗？
我让 LightSensorReport 只是数据的理由就是 - 它只是数据。它本身并没有真正做任何事情，但其他类会使用它(例如，另一个类可能必须将其序列化为不同的协议(protocol)格式；我不会将此责任放在 LightSensorReport 上，因为它什么都不知道关于二进制协议(protocol))。
那么，这种类是否适合良好的 OOP 设计，或者这是否表明我正在以错误的方式思考某些问题？
最佳答案
你的方法非常好。对于您来说，LightSensorReport 是一个紧密封装数据的对象。您不必被迫向在 OOP 中创建的类添加行为，但对象是范例为您提供的，它也适用于封装数据。此外，一旦您拥有了实体，您将来就可以向其添加行为。
某些语言已经定义了您创建的对象的行为。例如，在Java中，即使您没有在LightSensorReport类中定义方法，它也会继承父类(super class)Object中的方法，因此它在最后会有行为。
关于object-oriented-analysis - 纯数据对象在 OOP 设计中可以吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19988043/