Indirection
A few months back I was
reading this blog and kept this quote from
Alan Kay in my mind: "any problem in Computer Science could be solved by adding another level of indirection". I also think that more than three levels of indirection creates all kinds of new problems that can only be made worse with indirection (see my article on
Principle of Least Astonishment).
That said, I was reminded of a problem that I created (and also recently solved) with regards to outside resources to an application. Learn from my mistake. I know I won't be making this one again.
Let's say that you are shipping an application that requires ancillary files in order to make it work. Here are some guidelines for packaging up your files:
- Provide a folder for the files
- Allow that folder to live in a configurable location
- Allow sub-folders for the configuration that include:
- Product
- Version
- Target Language
And above all, name your folders well so that another person can immediately understand what you mean by your folder names.
An example might be:
FooWriter Resources
Version 2.2
English-ENU
French-FRA
Klingon-KLI
The mistake I made had to do with the versioning. In this case I was shipping resources that came from an outside vendor who had updated their code base and included new resources that couldn't co-exist with their old ones. Oops. I added in a new layer that included the version and created some legacy support code that would accept resources for that one particular old version in the old location, but would also look for it in the new place as well. In addition, I put in sanity-checking code to make sure that only compatible resources are loaded so that someone who overwrites the new resources with the old ones (or vice-versa) won't crash the code, but instead will be informed of what was expected and what was found.