Welcome to anti-refactoring lesson number 4.
Previously I posted about trivial programming errors, stuff for amateur programmers as in last case. Here we go for a more conceptual mistake.
Answer this question: from 1 to 10, how do you think it's smart to bind the name of a configuration property to the internals of your application?
In my opinion -1. Here I am going to tell you why.
What is god
The configuration is a business aspect your application. And one of the primary goals of a configuration property is to tell the user what application behavior he is modifying. So if the user finds a property like:
The user can understand that he is going to change the amount of time for which the splash screen will be displayed. And, also very important, the user can understand that the option value must be expressed in seconds.
Then, in your code you will have:
1Property configuration = ... 2long splashDelaySeconds = configuration.getProperty("myapp.splashscreen.display.seconds");
Notice that there is a 1 to 1 mapping between the property key declared in the configuration file and the key used in the source code referring to that. This allows modern IDE, like Eclipse, to navigate from the property file to the places on the source code where the property is used. If you never used it, try yourself: open a property file in eclipse and press CTRL clicking with the mouse over a property key; you'll see all the places in your code where that property key is referenced. If your IDE doesn't offer this facility, you can still do a full text search, using the property key, and you'll be able to understand how that configuration property is used.
What is bad
You may be unlucky like me, and get above approach anti-refactored using the following collection of bad practices.
First: including a package name, or any other internals, into the property name.
So you will have configuration properties like this:
Much more cryptic for almost everyone.
Not only: if your application internals change, also the option name changes. And there is no reason to change the same option across different software versions if the option is specifying the same behavior.
Second: notice that the time unit is gone. With the assumption that everything is expressed in milliseconds. Thing that could seem very obvious to some "experts", but believe me it is not obvious at all, when in a large system options became hundreds and nobody knows not only the unit of measures, but also what the hell they are supposed to do.
Third: breaking the property key mapping between configuration file and source code. So you will have:
1Property configuration = ... 2long splashDelaySeconds = configuration.getProperty(getPrefix() + ".myapp.splashscreen.delay"); 3...
No more "search" will be effective; the developers that maintain that code have to go crazy searching portions of the key, and guessing how the original developer constructed that. It's an extremely enjoyable way to spend your work time, I had this luck before and I can assure you.
Summarizing, the above example, including the package name (or the classname, or other stuff related to the implementation) in the property name is wrong for many reasons:
- You are binding a business behavior of your application (the configuration) to the internal implementation
- The same property may be used by classes contained in different packages, so the package name doesn't add any useful information (because it also becomes a wrong information)
- Mere implementation changes should not be impacting how clients use the software. If you move a class from a package to another... should you update the configuration files? Why?
- You break the 1 to 1 mapping between the keys specified in the property file and your souce code. Not having that it will become hard to find how a configuration property is used by the code.
So... don't do it.
|« Sep||Nov »|
- Android (3)
- Apple (30)
- Books (7)
- Eclipse (14)
- Errors (5)
- Firefox (7)
- Git (3)
- Hardware (18)
- Horror Code (8)
- Internet (21)
- Java (106)
- Life, universe and everything (45)
- Lifehacks (26)
- Linux (53)
- Opinions (26)
- OSX (11)
- OWNER API (3)
- Python (1)
- Software (35)
- Speeches and Conferences (8)
- Unix (5)
- Web (23)
- Windows (19)
Android apple architecture Bash bsd configuration CSS Development Düsseldorf framework free Git Google Hardware hdr How-To howto Java Karmic library Linux lion MacBook maven opensource Open Source Opinion os x OSX owner owner api patterns Pitfalls Practices properties Software TDD Testing tip tonemapped Tricks Ubuntu unix video Web