当前位置: 动力学知识库 > 问答 > 编程问答 >

design - Is it better to calculate object state from properties or vice versa?

问题描述:

For an arbitrary business object, is it better practice to calculate state from properties, or vice versa?

For example, if I had a TrafficLight with properties Red, Yellow and Green, is it considered better to create a function SetState(state) that toggles the lights as required, or to toggle the lights individually and have GetState() return the calculated state?

Is it simply a matter of preference, or are there certain situations that work better with one or the other?

UPDATE:

The answers/comments so far have made me realize that what I'm really after is whether to store the current state as individual properties or as a combined state. Would the traffic light state be best saved as Red=Off, Yellow=Off, Green=On or as State=Go?

I could easily determine either one from the other when reading the values, and in my real-world problem (as far as I currently know) the relationship of property-combinations to states = 1:1.

网友答案:

I believe it's not so much a matter of preference but rather a matter of usage.

For the traffic light example, you may have some internal timers and such running that alter the lit values. Users of your traffic light class would rather be interested in the state of the object, so the GetState method would be applicable much more so than a publicly available SetState.

However, there are situations where you'd rather set the state of an object and you're really interested in the outcome by reading different properties of that object.

So I'd say that usage drives this. Hope this helps!

网友答案:

As I understand it, direct property access is generally frowned on, as that exposes those properties on the surface of the object, and creates a semi-brittle model. Other objects that can interact with TrafficLight have direct access to modify the state of the object, and if you need to modify the way that state is managed internally to TrafficLight, you now have to also modify any objects that rely on TrafficLight exposing those properties.

Hiding properties behind methods to set and get state allow some level of abstraction. Other objects don't have to worry about /how/ TrafficLight works internally, they only have to know to use the proper getter/setter methods. This makes it easier to maintain the internals of your TrafficLight without forcing more changes to other objects.

A secondary benefit to handling it via getter/setter methods is that you can therefore also create listener-observer interactions by broadcasting changes during a set-method call. It's more flexible, in the long run, as I understand it.

Of course, if your object is more "throwaway" and needs to be kept very simple (say, for serialization purposes), then exposing the properties directly may be your best choice.

网友答案:

I have concluded that in most cases the best way to persist the data is as individual properties, but that adding additional properties which represent the combined state may be necessary if the property-combination to state relationship is not 1:1.

For the traffic light example, if SetState(go) and SetSate(goFast) both produce a combination of R=0, Y=0, G=1 then it would be necessary to introduce something like a GoState property if that information needs to be stored.

My reasons for this approach include:

  • much simpler code to get (and set, if allowed) property values
  • often many property combinations result in the same state (ex: R=1, Y=1, G=0 and R=1, Y=0, G=1 and several others are all Error states)
  • more true-to-life, i.e. physical properties of an object typically determine it's status, not the other way around.

I agree with the other answers that accessing (both setting and getting) the information depends primarily on usage requirements.

分享给朋友:
您可能感兴趣的文章:
随机阅读: