A confession. I never did manage to make design pattern work for me.
A disclaimer. I don’t think that this is because design patterns are in any way “wrong” or “bad”.
Yes, I do use them occasionally and Yes, I do know a fair share of them. However, I always have this nagging feeling that I should know more patterns, and at the end of the day, when I’m actually designing my systems I rarely go:
“ahmm I can use the XXXX pattern to do this”.
So why is this so? why after so many years of using design patterns talking about patterns and even arguing quite a lot about them, I still can’t make them work for me?
I wonder…
The human brain as a pattern matching machine
Start of July I attended at Vipul Kocher session during the SIGIST conference, in his session Vipul talked quite a lot about patterns and specifically about testing patterns. All and all it was a very interesting session, out of which I would like to repeat two main idea’s. First, Vipul initial claim was that our brain is basically a very sophisticated and efficient pattern matching machine. We use patterns on a daily basis. We see patterns everywhere, we recognize all kind of patterns we create new pattern, and often enough we even use Meta patterns (patterns which are used to create new patterns). No wonder our brain is such effective in matching patterns.
Learning to speak
Vipul’s second idea I would like to quote, is the fact that human apply this pattern matching ability in or language learning process.
And in the first time we are not even aware we are doing so.
When learning our native tongue, our brains learns patterns for matching single words, to match complete sentences, to match grammars rule and to match common mistakes. And it does so without us being conscious to the process.
The second time we learn a language the process is different, instead of absorbing the patterns instinctively, we apply a conscious learning technique.Instead of understanding specific word, we translate meaning from our native tongue, instead of deducting the grammar we LEARN grammars rules from books (or a teacher). This is also a way of learning. However in general the end result is inferior, usage of our native tongue will always remain easier and will always be of higher quality.
Misplaced Design Patterns
When talking about design patterns there are a couple of anti pattern I see in their usage. Again, I don’t claim there is something inherently wrong with patterns. I do see however problems with their usage. The most common issue I see, is a problem in applying patterns. Specifically, too often I see misplaced design patterns scattered around systems. Look at your current system you are developing. How many singletons do you see there? are all of them necessary? how many times you have argues with someone that while XXX is a great pattern, using it here seem to be out of place?
Initially I thought that this is caused by simple lack of pattern knowledge and understanding. However I think the reason is simpler than that. Our brain is always on the look for patterns, our thought process is rigged to order the world around us into known patterns and shapes. It does so instinctively all the time, and specifically during design it tricks us to see patterns which actually might not be there. It takes a really trained eye and conscious effort to compensate. Failure in doing so results in having a misplaced pattern in our system.
Design Pattern as a language
Haim describe in “Design Patterns and the Tower of Babel” one very important benefit of using patterns. Patterns serve as a common design language for us, and this is good.
However there is a catch. At least for me, the Design Pattern language is our second language. As a second language I will always find it harder to use. When using a secondary language (as in English ), I always struggle for the right words (patterns), I fail to understand the nuances behind them, I make stupid grammar mistakes and occasionally I use inappropriate words (if you don’t believe me read this article again). When I use Design pattern I feel the same, no matter how much effort I invested and will invest in learning patterns, I think that for me the cause is lost. I will not be able to use design pattern as my “native design tongue
So what should we do?
I see two options, the first is making sure that pattern does become the native tongue for new comers to our profession. On the upside design patterns has got a hold and I do see this more and more new comers learn them very early. However,I think that this process is going too slow. In order to actually see this done on a bigger scale, design pattern should be embedded into basic training and should be thought at universities (which I haven’t seen happening yet)
The second option is for people like me, those that will always have a different native “design tongue”. Like always, the first step is to admit that we have a problem. The problem is that the pattern language will always feel uncomfortable and be less effective for us. We still can and should use it, but when we do, we should be aware that we are “translating” and in the process our meaning can get twisted.
This is very frustrating. Especially when a “native pattern speaker“ meet a “second langue pattern speaker” like me. No matter how I try to avoid it, I end up reverting to my native language in order to “keep up” and when I do confusion start to hit (resulting occasionally in some heated arguments). Therefore the second step is to always keep in mind and be aware that this is happening.
When two “Foreign pattern speakers” meet
And last, and this is what I should always remember to verify, sometime on the other side there is another “pattern as a second language“ kind of guy. When this happen to be the case, we can sometime, just maybe, skip the whole pattern things. Chances are that it will be easier to communicate using our native design tongue.
So what are you?
- a native design pattern speaker?
- learnt design pattern as your second language?
1 comments:
In my opinion, design patters are crutch to help you express concepts that are otherwise difficult to express in certain programming languages, and thus have many pitfalls, which require guidance in the form of 'patterns'.
As languages evolve, these concepts can be expressed natively in the language and no longer require design patterns.
For example, in C#, a singleton doesn't really require a pattern - you can simply express it in a single line as a static readonly field with an initializer. The command pattern also becomes superfluous once C# introduced closures - you can achieve the same result without an explicit 'pattern'. C#'s Iterator Blocks moved the Iterator pattern into the compiler, removing the burden of knowing and implementing the pattern correctly. Further advances in the language and compiler will most likely continue this trend.
Some patterns (such as IoC) remain relevant because they have not been solved at the language level. Other patterns (such as MVC) are of a completely different kind - Wikipedia calls them 'architectural pattern', and architecture might never be solved by a language (and possibly never should be).
As these concepts move from an explicit pattern to an implicit grammar in your native language, the dissonance you experience between native concepts and foreign patterns will most likely be reduced and will eventually disappear. Since these concepts become native to the language, I'm not sure teaching them as explicit patterns is the right thing to do – just as you wouldn't teach native English speakers using a method meant to teach English as a foreign language.
Post a Comment