How to analyze a problem to match it with suitable design patterns?

Question

Hi,

I am wondering what should be the step by step analyzing approach to a well defined problem for figuring out the possible Design Patterns that can fit in the solution.

Any guidance you can recommend?

thanks

Answer 1

Designs Patterns are intended to encompass a broad variety of problem-solving tasks. So in the abstract you need to have a way to represent a variety of work being done, and a way to match a design pattern against that work. Doing this in general is "AI-hard".

A specific representation of "work being done" is obviously computer source code. Now the design pattern matching problem is one of matching against a set of code fragments that exhibit the problem of interest, and applying the "pattern" (e.g., solution) as a set of steps that modify the source code to achieve the desired result.

A tool that can express such patterns and effect automated source code changes is a Program Transformation engine. What you typically do with suc an engine is to collect a large set of design patterns together, instantiate them as sets of source-to-source rewrite rules, and then hand a chunk of code to the transformation engine so that it can do the pattern-match/replacement step. The hardest work, of course, is coding the design patterns as transformation rules, since most design patterns are written in prose and tend to be bit fuzzy about precise details. (The program transformation engine is very hard to build, but those are arguably already done :)

Program transformation engines have been used to implement refactorings (a well-known class of design patterns), language translations (massive "design pattern application"), and code restructurings such as reshaping APIs to meet new needs (one specific example I have done is automating the conversion of C++ code APIs to CORBA-compliancy).

Answer 2

Any design pattern repository will give you hints such as "this is useful when...", but usually there aren't any indexes that would allow you too look up "credit card numbers" and return "flyweight object". The nearest thing available is usually the loose grouping of patterns as behavioural, construction etc.

In my opinion there is no point in approaching a problem by wondering which design pattern you should apply. If you are sufficiently familiar with a pattern, you will notice straight away that it applies and how. If you don't see a fit, then trying to press a pattern into service merely so you can say "I used pattern XX, so the design must be good!" is a dangerous mistake.

There are people who even say that design patterns are a kludge in the first place, an indication that your language is not expressive enough. (This is not as crazy as it sounds; consider that things such as WHILE loops or hash tables were once absent from programming languages, and master programmers of that era would have to reimplement them again and again; now they are part of the syntax, and no one would dream of calling them 'patterns'.) Me, I'm not that extremist; I think a well-selected design pattern can be very useful indeed when you use it because you are convinced that it is a good solution, but that requires you to thoroughly understand it, and in my experience, this almost always requires having practiced it yourself. The value of patterns lies in giving a recognizable name to something that is often done, so you can remember it better and communicate about it with your peers.