Design patterns

Wow, one week without real Internet-access and straight thinking returned back to me. Sometimes I have the feeling, that the internet produces a real short concentration-time. I can't stay concentrated on one subject for a long time if I have Internet-access. I am in the wake of searching a place to live. After all my new job is in a different city. And driving the whole day long with the subway, I could observe myself to fall back into this state of deep thinking that is normally the result of long learning sessions in the library -- a state of meditation. I think most people forget, that there is not just the Zazen, the sitting meditation, but also Kinhin, the walking -- and searching for a new flat share is truely is. So I was thinking lately a lot about automata and computational models. This is a subject of great interest for me, because the depth of methods provided at university is not that great for modelling complex systems. There are subsubjects in here, like do I accept UML as the lingua franca of modelling. The obnoxious EPCs, ERDs are stuck into my head. But the real subject of this blog-entry is not the shameful being of the Internet, but design patterns. Design patterns are well-known in the developer community, but there is a certain argument, that they are just poor hacks for a less powerful language than say LISP.

Many patterns form a language

This is the answer. The problem here is that many people see this from a too technical perspective. But CA was thinking about something else. The pattern is a means for formulating an idea. And after you have collected a lot of patterns it is natural that they are implemented as generic algorithms and such. I am very interested in travelling so this comes out naturally for me. Imagine the following situation: You visit a new country, say France. And you don't know the language, yet. So you use patterns. A pattern is the triumphirat of a problem, the context and the solution. Given the problem of starvation, you want to eat something i.e. the solution. The context is that you are a stranger with no money but good looking. I now will introduce the pattern Fancy someone for a meal. And now you can go on and describe an algorithm, a step-by-step instruction how to seduce someone in this special case. The next thing could be that you want to sleep in this country. Now it is possible to define the Fancy someone for a place to sleep. This could be a whole language for your state machine:

-- S = { hungry+tired, full+tired, hungry+awake, full+awake }
-- E = { Fancy_someone_for_a_meal,
         Fancy_someone_for_a_place_to_sleep }
-- T = { (hungry+tired X Fancy_someone_for_a_meal -> full+tired),
         (hungry+tired X Fancy_someone_for_a_meal -> hungry+tired),
         (full+tired X Fancy_someone_for_a_place_to_sleep
          -> hungry+tired),
         (full+tired X Fancy_someone_for_a_place_to_sleep
          -> hungry+awake),
         (full+tired X Fancy_someone_for_a_place_to_sleep
          -> hungry+tired), 
         ...
         handwaving
         ... }

A pattern is a relation putting a new dimension to algorithms and helps building a language. Quicksort for example is not the fastest algorithm for every case in every circumstance. To document this you can use patterns. Now my coffee is finished. Back to work.