Question

I’ve been reading various programming styles like XP (writing the test first), and came across a Java book that just has design patterns, what seems to be like pseudocodes.

What are these design patterns used for ? what does design apttern in the context of programming refer to and what are it’s applications ? Is it like blue prints for building a domain specific application ?

Answer 1

A Design Pattern is a general reusable solution to a commonly occuring design problem. Actually, we can generalize that: A Pattern is a general reusable solution to a commonly occuring problem. There are not only Design Patterns, there are also Coding Patterns (although we don’t call them that, we call them Idioms), Architecture Patterns, User Experience Patterns, Process Patterns etc.

However, there is a small problem with that definition: in programming, we call a general reusable solution to commonly occuring problem a Program. So, in other words, if you have a recurring problem, you write a program, and only if you can’t write a program, then you need a Pattern.

So, an alternative definition would be: A Pattern is a Program that you cannot write because your Programming Language is too weak to express it.

So, in general, you should try to use a better Programming Language before you try a Pattern. However, Programming Language Design is all about trade-offs: it’s simply impossible to design a Programming Language which can express all problems equally well. So, having some Design Patterns in your code is perfectly fine, but you shouldn’t have many of them and you definitely shouldn’t have any Patterns in your core business logic. That’s a sign that you chose the wrong programming language and no pattern can fix that.

Here’s an example: in assembly programming, having a parametric piece of behavior shared between different parts of the program is a commonly occuring design problem. And there is a design pattern that solves that problem: it’s called a Subroutine. But in a different language, and in fact in pretty much all modern languages, subroutines (sometimes called procedures, functions, methods, routines, subs) are built right into the language. They aren’t a Pattern, they’re just there and nobody even thinks about them anymore. So, if you have just one or two subroutines in your code, that’s fine. But if you have many of them, assembly is probably not the right choice.

Some other examples: In a prototype-based OO language, the Prototype Pattern is built in. In a language with multiple dispatch, the Visitor Pattern is built in. In Ruby, there are no constructors, you always use Factory Methods without thinking about it. In delegation-based OO languages, the Decorator Pattern is built in. In languages with higher-order procedures, the Iterator Pattern is built in. In languages without mutable state, the Iterator Pattern is actually an Antipattern.