Is coupling property file values with data in a database an anti-pattern?

Question

I'm working on an application where there are a few configuration values defined in properties files whose values or valid ranges are in some way dependent on data stored in a database.

This seems wrong for a few reasons but I'm struggling to find a name for this or indeed any published article that might suggest it is bad practice. Could anyone advise?

Answer 1

Your pain has a name, and it is coupling.

The property file -- which I gather is either part of a server's configuration or is bundled with the application -- is coupled to the database. Changes in the database will ripple to the property file.

It's not the worst kind of coupling -- that circle of hell is Pathological/Content coupling -- but coupling it still is.

Answer 2

On 15 February, 2016, StackOverflow user "zerobandwidth" stated that it's a bad idea to have your configuration settings be validated according to circumstantial bounds derived from database data. There, now there's post where someone says it's a bad idea. o.~

Seriously, though, any time you're trying to do input validation based on external circumstances, particularly when the derivation of those standards depends on something as fragile as a connection to a network or database, you're going to have a bad time.

If we have to invent a name for this pattern to make it feel more official, how about "unreliable fundamental dependency". That seems to have a suitably smelly connotation, right? ^_^

Answer 3

There are a few anti-patterns that come to mind. The most appropriate one would probably be softcoding (the opposite of hardcoding values). Avoiding hard-coded values and "magic numbers" is generally a good thing, but not if taken to the extreme. From the Wikipedia entry:

The term is generally used where softcoding becomes an anti-pattern. Abstracting too many values and features can introduce more complexity and maintenance issues than would be experienced with changing the code when required.

Since you asked for published articles, more details on softcoding can be found in The Daily WTF, where Alex defines softcoding as...

the practice of removing "things that should be in source code" from source code and placing them in some external resource.

From what you've described, these values should be stored (or possibly calculated) in source code, or also in the database where the values they depend on are stored, not in external property files. So yes, I would agree that there is indeed a bit of "design smell" here.

To a lesser extent, you could argue that this is a case of Cargo cult programming being applied.

Cargo cult programming can also refer to the results of applying a design pattern or coding style blindly without understanding the reasons behind that design principle.

Not quite the same thing as applying a Golden Hammer, but somewhat similar in principle.

(Be careful when presenting "authors" of such code with these definitions, though, as most developers tend not to appreciate having anti-patterns in their designs pointed out to them.)