I have used data-driven design in the past and it has worked quite well. What I dislike about it is if you need some form of a string whose value has to be updated based on other values. e.g., "Exports %x percent of %y". In that case you will need an extra column serving as an identifier, to tell which variable in your class will correspond with the conventional symbols %x and %y. Now, don't get me wrong, there might be a way around this, but this is not the point of this thread (albeit I would not mind having an answer to this one as well).

What I fear about data-driven design is tight coupling. I may be abusing the term for this scenario, but allow me to elaborate.

When you have a template class, call it Vendor, it will be initialized in run time and have the data from your data source (xml/csv/txt/etc.) fed into the class's members. The idea of tight coupling is to prevent co-dependency, dependency and assumptions of one class for another's functionality.

Now, people have been advertising data-driven design as a loose-coupling method, but your class's structure HAS to assume what data there is inside your data source. For example, if you have four columns, each representing a variable in your class, and you decide to put in a new column, the class has to be redesigned for this purpose. Additionally, if you are missing such a data source file, you are dealing with a non-functional class instance (or at least non-functional to the way it was designed to be).

My question is, doesn't data-driven design actually enforce logic coupling between classes? Also, what happens if you have a class whose sole responsibility is to parse the data files? Which class references this parser, the class that needs the data (coupling) or a third party class? Would you instead use a delegate for this?

I am all for a data-driven design, but I cannot help but notice certain flaws in certain situations (well, nothing's perfect). It's just hard to maintain from a designing point of view, because an extra column in between existing columns breaks the entire output.

What am I missing?


  • 1
    This doesn't really align with any definition of data-driven design that I've read; can you elaborate what you mean by "data-driven design"? Jan 27, 2017 at 23:25

1 Answer 1


"Coupling" is one of those words which everyone thinks is dirty. The fact is, without some degree of coupling, no programming would ever be possible. The key is to be able to distinguish between good and bad coupling.

In my opinion, "bad coupling" is when there is a physical dependency where no logical dependency exists. In other words, if you have to modify code that seems unrelated to the thing you're trying to do, you probably have bad coupling.

It sounds like you have a series of classes intended for data representation. Bad coupling would occur if those classes were coupled with the logic for persistence (e.g. if they contained code for storing the data to a filesystem or database). But it is not bad for those classes to be coupled with the schema, since schema defines the logical representation, and naturally the classes should be in accord with that representation.

  • Hi John, since you focused on the tight coupling, I will ask you a more direct question on it. In the example I've mentioned, Vendor, assume you create another class called Product. Typically, in this scenario, you could have Product[], as an array, describing what is being sold by this vendor. Now, this is a hard reference of Product class to Vendor. If Product ceases to exist in the assembly or overall project, Vendor becomes automatically broken. Here, you have a logical dependency, as you described, but conditionally functional. What's your way around this?
    – Aris M
    Jan 27, 2017 at 22:30
  • 1
    As for the data-driven paradigm, I still fail to see how this is not coupling in the bad sense. Your classes rely on the structure of an external file, isn't this a bad thing?
    – Aris M
    Jan 27, 2017 at 22:31
  • 2
    If Vendors stop selling Products I'd say that you are up against a significant update. You can't escape updating code when your business changes! (At least I hope not, we'd be out of a job). The point is to avoid updating unrelated code.
    – John Wu
    Jan 27, 2017 at 22:33
  • 1
    Classes do not rely on the structure of an external file (unless you are an unusual dev you probably don't have a clue how SQL structures its files). It is reliant on the schema of the database, which is a logical structure tied to the manner of your business operations. This is about the same as relying on an interface. Certainly interface dependency and loose coupling are routinely said to coexist.
    – John Wu
    Jan 27, 2017 at 23:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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