I’m sure this article is going to be a bit offending for some software developers, but there’s something with software design patterns that has been irking me for years, and recently I discovered the reason for that. In the hopes that there are others that think alike, I’m going to explain the reasons here. Maybe it does something good.

In my UAS (and I’m sure in most of the others with software development), the software engineering lectures consist of memorizing software design patterns. I’m pretty sure it’s that way because it’s convenient for the teacher, it’s quantifyable (“We have explained 15 design patterns in this lecture! The other UAS only does 13!”), and it’s testable (“To which design pattern does this UML diagram fit?” — That’s a real question from a Software Engineering test).

However, it completely misses the concept behind software engineering and programming itself. I think design patterns are a bit like LEGO™ pieces: You put in an iterator pattern piece, stick it to a singleton pattern piece and attach an observer pattern piece at the top, and there you have your helicopter that can be built by a five-year old.

That’s completely not how software programming is really done by professionals. When you have a problem to be solved during development, you just think about it and come up with a solution (usually within minutes). Programming has a very limited solution space, so there are a very limited number of solutions you could come up with. When you do that, you usually do something that somebody incidentally wrote down as a software pattern, even without you knowing about it. So, why should I learn those patterns? The ideas behind them come naturally when they’re needed anyways.

Maybe I should differentiate a bit at this point. There’s the MVC pattern (“Model-View-Controller”). This pattern is different, because it does not describe a class hierarchy, it describes a way of thinking. That’s what you really should learn when you want to do professional programming. Programming is not about “should I subclass this class”, it’s about “what are the general structures of my program?”. Those are things that cannot be learned by memorizing, they have to be learned by experience (and doing it wrong the first time around — that’s what antipatterns would cover). Either that, or the explanations of what to do and what not to do become very vague. There’s no UML in there! Sidenote: I actually considered writing a book about this (working title “The Art of Software Design”), but then I remembered the horrible experience of my last book attempt and let it go.

So, one of the major things I hate in blog posts is when they go on forever, without adding anything more after a point (or having tons of fillers between the important stuff), so I’ll just stop here. If you have any comments/questions/complaints, feel free to comment below, twitter me or send me an email.

Maybe I’ll visit this topic again in the future with some concrete examples (let’s call them the “Software Design Pattern Antipatterns”).

« »