对于任意业务对象，从属性计算状态是否更好？反之亦然？
例如，如果我的TrafficLight包含属性Red，Yellow和Green，那么创建一个切换的函数SetState(state)会更好吗？根据需要点亮灯光，或单独切换灯光并让GetState()返回计算出的状态？
这只是一个偏好问题，还是某些情况与其中一个更好地合作？
更新：
到目前为止，答案/评论让我意识到我真正想要的是将当前状态存储为单个属性还是组合状态。红绿灯状态最好保存为Red=Off，Yellow=Off，Green=On还是State=Go？
我可以轻松地在读取值时从另一个中确定一个，在我的现实问题中（据我目前所知），属性组合与状态= 1：1的关系。
答案 0 :(得分：1)
我认为这不是一个偏好问题，而是一个使用问题。
对于红绿灯示例，您可能有一些内部计时器和这样的运行，可以改变亮起的值。您的红绿灯类的用户宁愿对该对象的状态感兴趣，因此GetState方法比公开提供的SetState方法更适用。
但是，在某些情况下，您宁愿设置对象的状态，并且通过阅读该对象的不同属性，您真的对结果感兴趣。
所以我会说用法驱动这个。希望这有帮助！
答案 1 :(得分：0)
据我了解，直接属性访问通常不赞成，因为它暴露了对象表面上的那些属性，并创建了一个半脆性模型。可以与TrafficLight交互的其他对象具有修改对象状态的直接访问权限，如果需要修改TrafficLight内部管理状态的方式，您现在还必须修改依赖于TrafficLight公开这些属性的任何对象。
隐藏设置和获取状态的方法背后的属性允许某种程度的抽象。其他对象不必担心/如何/ TrafficLight在内部工作，他们只需要知道使用正确的getter / setter方法。这样可以更轻松地维护TrafficLight的内部结构，而无需对其他对象进行更多更改。
通过getter / setter方法处理它的第二个好处是，您也可以通过在set-method调用期间广播更改来创建侦听器 - 观察者交互。从长远来看，它比我理解的更灵活。
当然，如果您的对象更“一次性”并且需要保持非常简单（例如，为了序列化目的），那么直接公开属性可能是您的最佳选择。
答案 2 :(得分：0)
我得出的结论是，在大多数情况下，保留数据的最佳方法是作为单独的属性，但如果属性组合与状态关系不是1：1，则可能需要添加表示组合状态的其他属性。 / p>
对于红绿灯示例，如果SetState(go)和SetSate(goFast)都产生R=0，Y=0，G=1的组合，则有必要引入如果需要存储该信息，则需要GoState属性。
我采用这种方法的原因包括：
R=1，Y=1，G=0和R=1，Y=0，G=1以及其他几个都是Error州）我同意访问（设置和获取）的其他答案信息主要取决于使用要求。