You guessed it, I don't approve. Here we go!
Communicating with other coders or teaching a youngling the skills of our trade obviously requires a specialized language, but why should such a language be needlessly convoluted? Acronyms are fine, I enjoy baffling civilians on the Information Highway as much as the next fellow, but I don't see why some of my peers apparently enjoy throwing around words that aren't in our common vocabulary.
"You ought to enlarge your vocabulary then," they proudly boast. Meaning, of course, that my base knowledge of the art of programming is not enough, and that I should strive to continue learning. I don't see anything wrong with that motive, besides perhaps the inevitable unveiling that there is no Santa. What makes my bile rise, however, is the suggestion that I should learn so-called "patterns".
Remember how someone once told you about the Singleton Pattern, and you thought to yourself, "Yeah, I can see how that would be useful"? Well, it's hard not to see how a global variable can be useful. Funny thing is, you already knew what that was, but you hadn't heard the fancy name before. In fact, what's hard to see is why such a simple concept as this needs to be given a name at all.
Granted, the word "singleton" communicates a little bit more than just "global variable". Fine. So how many times has the word "singleton" been bandied about in a useful context? A setting where the concept of a singleton actually made sense? Few, I wager. How often is it really necessary to enforce that a class be instanced only once? Dude, if you only support one graphics adapter, then simply create a single instance of your GraphicsAdapter class! Exactly who are you protecting your code from by turning it into a singleton? Code in your sleep a lot, do you? Moreover, rather than improving upon existing code, the singleton will more likely just add to code complexity.
What's more, the singleton is just an example; it's definitely not the only design pattern to suffer from complexity. I daresay any pattern adds clutter and increases opacity. I base that statement on this simple observation: If your design needs to be explained, it is too complicated.
As soon as you find yourself wading through code in order to find out what is really going on, something is amiss. Stepping through function calls into other function calls of class methods ridiculously and indecipherably abstracted to the extremes, with useful comments such as //I just learned the Utility pattern lol :) is enough to make a grown man cry. Naturally, this problem doesn't always stem from the use of patterns alone, but frivolous use of them will certainly lead downhill.
I heard someone say this: "I'm not proud of this code, it isn't a very good pattern." I'm sorry, what? Here's another quote: "We need to think of a better pattern for this part." Woah, hold it - buzzword alert. Is code in any shape now equivalent to some sort of pattern? Is a for-loop a pattern then? Seemingly, it's not enough to just write code anymore, oh no, it has to be designed. It has to be architected. Cue Vader's theme.
Architecting code doesn't imply creating dense structures that are difficult to navigate and understand. The use of patterns for the sole reason of using patterns, however, does. This is the main problem with patterns. Naive application of perceived superior dogmas by fanatics and bumbling fools who believe that "refactoring" is a new and revolutionizing concept. Sit down Java programmers, nobody cares about your "humble opinion" or otherwise.
It all boils down to the definition of perfect code, the shimmering idea of a brilliantly logical construct that only exists in our mind's perfect world. Some seek to live by the rules of The One True Brace, while some pray in the Hungarian church of True Notation. Others again kneel at the chapel of Patterns. I propose that we all put ourselves above these mere tools, instead of bowing and scraping to them as our gods or demons. Less crusading for the causes would also be nice. But then again, so would world peace.
Showing posts with label design. Show all posts
Showing posts with label design. Show all posts
Tuesday, January 27, 2009
Subscribe to:
Posts (Atom)
