Introduction to Part 1
By the time you have written your abstraction layer, you have essentially written your own framework. Chances are, you are not a good framework writer, and it’s going to suck, and you are going to realize that one or two versions down the road and re-write it. © RedMonk in Java’s Fear of Commitment.
While there is a lot written on how difficult it is to write a good abstraction layer, there is very little advice on how to avoid the worst evil of the abstraction layer: obfuscation. As I scoured the internet looking for any discussion on this topic, my search results were a lot more sparse than I was expecting. There is a very succinct blog entry by Rhett Maxwell that turned up in my results that summarizes some of what I’d like to say in a single sentence: Most of the books out there that teach OO design talk about Abstraction, but they do not warn about Obfuscation at all. Its a shame.
And to those of you wondering why this type of obfuscation is a problem, let me clear it up. Obfuscation at its most harmless simply confuses people. Obfuscation at its worst makes people stupid. When the most brilliant programmer can no longer figure out how to get from point A to B, even though they are right next to each other, all their genius is useless.
I will be dealing with these issues in several sections:
- Decorating Objects
- More on Naming
- Dealing with Multiple Function Signatures
- Comments Don’t Fix Code
- Wrapping Parameters
- Calling Function References
The “solution” that many have come up with is to abstract these concepts using a decorator function. There’s nothing wrong with doing this, it can significantly clean up your code; the problem is the direction of the abstraction. Many of the tools available to abstract OO use naming conventions and concepts more akin to rigid languages, such as Java or more powerful languages, such as Python.
The solution isn’t getting rid of the abstraction, it’s conveying the idea properly. We need to do this by unlearning a lot of the terminology that we’re used to. If the terminology of other languages was created to describe a specific idea of another language’s implementation, why do we think we can just apply it to the idea we’re trying to convey, and do it without any extra baggage?
More on Naming
If you are really worried about reducing the size of your files, do it any other way. Use acronyms or use a code shrinking tool. Naming things properly is one of the most important things you can do in the long term. And be wary of those that claim that a ridiculous name is okay to use so long as you force it into the programmer’s lexicon, it is a sure sign of a lack of priorities.