Pragmatism or purity - Should we rely on GUI framework to store program state?

I was once in charged of creating a C# custom user control. It's a control with a bunch of collapsible sections. The control that user could click on it to toggle between collapse/expand state is a label control. There's an image control right beside it that would change state to indi开发者_Go百科cate whether the particular section is collapsed or expanded. Somewhere in the control, I need a function to return the state of any particular section. The question is, should the function return the state based on the image control's state, or should we introduced an additional variable that would store the state, with the additional risk of it being out-of-sync with the current state?

---

Most of the time, when people go with a "pure" solution to problems like these, they're just hiding coupling, not removing it. The coupling usually represents the essential complexity of the problem they're trying to solve. Since it can't be removed, it may as well be implemented in a straightforward way.

Your case is no exception. Unless you think that there's a decent chance that the getter for the image control's state will change in the future (not likely if you're using a stable framework), using an additional variable that's always supposed to have the same value as the image controller's state just replaces explicit coupling with slightly hidden, implicit coupling. This gains you nothing and increases complexity and therefore bug potential.

---

Redundancy is pointless. I say just read the image state, if that can be considered empirical.