C# – Data-Driven Design & Coupling – Mother may I?

  softwareengineering

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?

Cheers

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.

4

LEAVE A COMMENT