I have a system that has configurable state values, like BoxCount, “Number of Visible Boxes on the screen”. If I am using some heavyweight set of patterns (like MVC) that enforce the creation of multiplicities of classes, and if I follow design patterns, I often find the case where some tree of objects exists like this:
- CModelBox = a model class dealing with some box count
- CViewBox = a view class dealing with showing the count of boxes
- CControllerBox = a controller class dealing with some box count.
If each of the above had a field (a member variable) called Count, and that one fact (how many boxes?) is repeated in the implementation, and then somehow has to be “updated” in every which way, is there a name for this problem? Is it known by some name, as an anti-pattern, or by some other formal name that might help me do some research on how people identify, and remediate these problems in their application designs?
The very specific problem I observe most often is that any time you have two fields instead of one, you CAN have a difference, and then the question is, does the difference have meaning, or is it an accident. If it’s an accidental (and permanent rather than temporary) difference, a failure to keep things in sync, then it’s a lurking bug.
Update: I suspect that people who build systems according to “SOLID” OOP principles might have a definitive name for this problem, and if they do, that’s the particular answer I want. This is not really an opinion, it should be backed up by some citation from a SOLID OOP source, such as Uncle Bob, or one of his minions.
9
I call this “redundancy”.
Is redundancy good or bad?
It’s good if it exists for the purpose of correcting errors,
and if there is a mechanism in place for correcting those errors.
It’s bad if it’s just “there”, because of just what you describe.
It can get inconsistent, and then you’re at sea.
One method that is sold as a technique to prevent the inconsistency is notifications.
I don’t care for those, for a variety of reasons.
Rather, what I try to do is:
-
Minimize redundancy, so as to minimize the opportunity for inconsistency. This may mean sharing data, or something like that. This is the reason databases are “normalized”.
-
When some redundancy is unavoidable, as it often is, understand how to deal with it.
I first try to understand which representation is “the boss”, so if different data structures disagree, I can tell which one to believe.
Then, I always try to follow a policy of tolerating inconsistency.
I try to have a method to reconcile differences where they occur.
I tend to use algorithms like “merge” and “diff” to do this.
This opposes the strategy of using notifications, but I find it is much more reliable and efficient.
P.S. As an example, a long time ago I stumbled on differential execution which is one way to manage redundancy between a program’s state and its UI.
4
“Wet.”
More precisely, failure to “stay DRY.”
14