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
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?
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
Green=On or as
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
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
SetSate(goFast) both produce a combination of
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:
G=1and several others are all
I agree with the other answers that accessing (both setting and getting) the information depends primarily on usage requirements.