2

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.

closed as primarily opinion-based by gnat, Jimmy Hoffa, user22815, user40980, Bart van Ingen Schenau Feb 7 '15 at 14:21

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    Per On the troubles of naming and terminology, 'name that thing' questions are not necessarily bad. – Dan Pichelman Feb 5 '15 at 16:37
  • 2
    You don't have to have a field ("Count") in each, only in one place. If the Count has some meaning to your domain, put it in CModelBox. If it is only relevant to the presentation, keep it in CViewBox. – christofr Feb 5 '15 at 16:40
  • 4
    copypasta, inconsistency – herzmeister Feb 5 '15 at 16:47
  • 1
    that's just data consistency/synchronization. People might say it's DRY->Don't Repeat Yourself, but that's more about the code itself - don't repeat the same blocks of code. Often times you'll have a piece of data in a presentation layer, a model layer, and a persistence layer. The solution is people try to come up with automatic-data-binding techniques that automatically synchronizes those pieces of data, but most people would refer to it as just data synchronization. – Jimmy Hoffa Feb 5 '15 at 16:54
  • 2
    With regards to databases, the equivalent of DRY is third normal form. Not sure if it can be applied to data in the code (free variables, object attributes, etc) – Izkata Feb 5 '15 at 17:04
5

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:

  1. 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".

  2. 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.

  • you prefer diff over change notification, big surprise there ;P +1 though because it's a good answer and your approach though unconventional makes a lot of sense in a lot of ways. (I'm an unruly fan of eventing/messaging myself but at least your approach of diffing is both consistent, simple, and far better than the more conventional inconsistent applications of random techniques people tend to use) – Jimmy Hoffa Feb 5 '15 at 18:11
  • @JimmyHoffa: I use events at low frequency, like once in a while just do a regeneration, but for high frequency messages are just too likely to get dropped or duplicated. Plus, often they are self-cancelling like "insert X", then "oops, don't". Plus, notifications get buried in classes, and they can easily go wild, soaking up CPU. – Mike Dunlavey Feb 5 '15 at 18:17
  • 2
    I understand. I've actually looked over your differential execution concept a fairly bit after other posts you've made around here, and I believe I have a firm grasp on it. It's quite inventive and I do like it. – Jimmy Hoffa Feb 5 '15 at 18:25
  • 1
    @JimmyHoffa: Thanks. I guess I'm a bit of an outlier sometimes, but I am impressed with the fact that there are some really talented and helpful people on these sites. – Mike Dunlavey Feb 5 '15 at 18:29
-1

"Wet."

More precisely, failure to "stay DRY."

  • 2
    Dry refers to repeating code. Often times people have data in their DB and their applications memory and maybe a remote cache also, this is normal and not a failure to be DRY. Failure to be DRY is when you copy some code from one class to another class to another class rather than creating a reused abstraction where that code lives once. – Jimmy Hoffa Feb 5 '15 at 17:03
  • 1
    @JimmyHoffa Not according to the authors of The Pragmatic Programmer: "Most people take DRY to mean you shouldn't duplicate code. That's not its intention. The idea behind DRY is far grander than that. DRY says that every piece of system knowledge should have one authoritative, unambiguous representation. (...) A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." Note that my web browser isn't part of SE's system. – Doval Feb 5 '15 at 17:10
  • 2
    Note that 'wet' has been retconned to mean 'Write Everything Twice', which I find quite appropriate. – Kilian Foth Feb 5 '15 at 17:16
  • 1
    @Doval that's interesting and new to me, also I couldn't disagree more with it. That's either poorly explained or totally irrational because everyone has data duplicated, the only thing you can not duplicate is the code that accesses the data, but data must be duplicated both for redundancy and communication. The idea of not having data in multiple places makes no sense at all. As soon as you read a piece of data you've duplicated it into wherever you read it to. – Jimmy Hoffa Feb 5 '15 at 17:35
  • 2
    +1. I agree with the DRY usually meaning blocks of executable statements. I always use DRY to refer to blocks of repeated code. But then "int FieldName;" repeated in various places is a line of code that is repeated,and so in a way, DRY also applies. – Warren P Feb 5 '15 at 19:24

Not the answer you're looking for? Browse other questions tagged or ask your own question.