Tight Field Coupling

TightFieldCoupling is a characteristic of object oriented and structured languages in which the members of each class/object are tightly coupled to each other. This means that if you want to only use some of them, or you want to add more, you have to do this in multiple places in your application and then recompile. Worse yet, if you want to do clever things with your fields like display a list of them, you must use reflection or some other clumsy approach to get at the compiled definitions. The problem isn't really the fault of object orientation because it actually predates object orientation. The problem was introduced when we introduced structures. The structures paradigm has been useful for many years but it is now running out of steam.

• Aren't members of Objects supposed to be "tightly coupled"? What distinguishes this from EncapsulationDefinition?
  • Of course they are. Nothing distinguieshes it from that. I think the hinted problem is that there is no way to express the coupling of fields in an abstract way. Synchrony of fields can be stablished only by manually coding the updates in both direction. This problem also manifests itself with tightly couples fields in different classes. If you update one of them (be it by setter, some mutation or reflection) you always have to have some means to update all the related fields. You can do so by provising sufficiently refactored code for the fields in question, but that can be laborius.
    • You might consider the ObserverPattern to avoid duplication of data.

---

One possible solution is a DataDictionary, either in code or a database. However, having new or changed fields automatically propagate into various sub-systems can be problematic if you don't carefully test each one to make sure there are no unintended consequences. It also takes experience to use DD's effectively. In my opinion they would be superior to the code-centric alternatives, but more developers would have to get used to them to avoid them becoming a maintenance risk, as replacement staff won't be used to them. QwertySyndrome.

How does a DataDictionary help with this TightFieldCoupling?

In general, use of explicit, specific by-value references -- whether identifiers or foreign keys -- results in tight coupling and/or brittle code. Unfortunately, alternatives are almost invariably complex and/or risk ambiguity. The solution is to reliably propagate changes, rather than change how references are done.

It depends how you define "coupling", which is not an easy task. It's not always easy or practical to know that changing X will break Y. It's a matter of balancing the frequency and magnitude of risks with labor costs. Manual propagation tends to force one to check out each module for impact, but is labor-intensive. Auto-propagation may save a lot of up-front labor, but can create panic situations when something unexpected breaks. SoftwareEngineeringIsArtOfCompromise. -t

For an typical example of breakage, adding a new field may result in a new field propagating to a printed report (or screen), making the report too wide to fit on the paper, creating either truncated columns or screwy wrapped formatting. A change impact analysis would normally bring one to ask if the new field is suppose to show up on each report; and if there is no room, what other field gets taken out to make room. -t