Design patterns are from hell!

For someone who likes to think about the philosophy behind a problem before solving it, design patterns haven't made any sense at all right from the beginning. The way I have always seen design patterns are as thumb rules for craftsmen and not something about which you write a research thesis.

If you are writing a thesis about the way human mind thinks in patterns and the role patterns play in reducing our cognitive load, etc. that is a different thing. But, to create a catalog of recurring patterns, that are explained using English (!) without really explaining an underlying philosophical concept, hadn't really appealed to me (as a research dissertation) at any time.

But to be fair, I do think that thinking in patterns (not design patterns) reduces the first step in problem solving -- which is to understand the broad direction in which we should look. But that is just the first step. After this, we should start really understanding the problem.

As a student I had proposed on the Object Technology Users Group (OTUG) list that what we really require are Analysis Patterns and not Design Patterns. Analysis patterns are recurring patterns of the problem space. For instance, for some problem in multi-agent systems, we can say that this is a case of the game theoretic stag-hunt problem. The game theoretic prototype is the analysis pattern and it gives us a broad direction in which to start thinking to model the problem.