A Fine Line Between Abstraction and Obfuscation

By on September 24, 2007 9:09 pm

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.

JavaScript is incredibly susceptible to becoming accidentally obfuscated. In the next month or so, I want to go over various common methods of abstraction that I have seen widely used in JavaScript and discuss how and why they can lead to obfuscation.

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 Ideas of JavaScript

Decorating Objects

The Oxford Dictionary says that abstraction is “the quality of dealing with ideas rather than events.” For programming, we might say that abstraction is “the quality of dealing with ideas rather than their implementation”. Write this down, it’s precisely what we need to remember when we’re manipulating objects in JavaScript.

One of the subjects that causes a lot of confusion about JavaScript among novice programmers is how to use it for object oriented programming. Though I personally find the mutability of JavaScript, along with its prototypal inheritance, to be relatively simple, flexible, powerful, and beautiful, many find it baffling.

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.

Using our definition of abstraction, these tools are using the ideas that represent Java’s implementations to try to represent the implementations of JavaScript. Before long, you end up adding the idea of multiple “superclasses”, an idea that simply doesn’t have an implementation in JavaScript. You’re then left with a programmer wondering why instanceof is evaluating to false even tough their superclass is in the list.

It also means that we lose out on some of the ideas of JavaScript that are totally unique to the language. The call and apply methods immediately spring to mind as incredibly useful tools for doing OO in JavaScript.

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

A lot of these utility functions end up becoming grossly weird in the name of saving bits. Only with the worst possible logic could $ be an acceptably meaningful function name. In most JavaScript libraries that use the $ function, it is merely an abstraction for the document.getElementById function (which is admittedly clunky). They’re taking a descriptive name and replacing it with a non-descriptive one. Abstracting in this manner is obfuscation, by anyone’s definition.

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.