+972 52-548-6969
Design patterns in the test of time
Amazon tells me that I purchased this book in Sep 2004, and have since then misplaced it, for some reason. I remember how important this book was to shaping how I thought about software. For the first time, I actually have the words discuss what I was doing, and proven pathways to success. Of course, we all know that… it didn’t end up being quite so good.
In particular, it led to Cargo Cult Programming. From my perspective, it looks like a lot of people made the assumption that their application is good because it has design patterns, not because design patterns will result in simpler code.
Now, this book came out in 1994. And quite a bit have changed in the world of software since that time. In this series, I am going to take a look at all those design patterns and see how they hold up in the test of time. Remember, the design patterns were written at a time where most software was single user client applications (think Win Forms, then reduce by nine orders of magnitude), no web or internet, no multi threading, very little networking, very slow upgrade cycles and far slower machines. None of those assumptions are relevant to how we build software today, but they form the core of the environment that was relevant when the book was written. I think that it is going to be interesting to see how those things hold up.
And because I know the nitpickers, let me setup the context. We are talking about building design patterns within the context of .NET application, aimed at either system software (like RavenDB) or enterprise applications. This is the context in which I am talking about. Bringing arguments / options from additional contexts is no relevant to the discussion.
I am also not going to discuss the patterns themselves at any depth, if you want that, go and read the book, it is still a very good one, even though it came out almost 20 years ago.
Comments
You old fart! Can't wait to see what you have to say on this! Keep 'em coming - and thx!
The reason for the Cargo Cult mentality with design patterns is people forget they are meant to fall out of good code, rather than be injected into bad code.
Obligatory Link to Resign Patterns: Ailments of Unsuitable Project-Disoriented Software (http://www.lsd.ic.unicamp.br/~oliva/fun/prog/resign-patterns).
Nice!
cool! looking forward for the upcoming posts
I would blame the Cargo Cult mentality on those who seek prescriptions rather than understanding. Whether the individual Go4 patterns are still relevant or not is less interesting than whether the concept of patterns is still relevant.
Design patterns aim to solve deficits in a language by providing a standardized solution to these deficits (i.e. common problems). Specifically, the GoF patterns solved 1994 C++ problems. It shouldn't be surprise that modern languages and techniques solves these problems better.
I think the importance of the book is in the pattern thinking that it brought into the software world - the fact that solutions are only good in context and the technique to describe these solutions and problems, building a vocabulary etc.
The GoF book almost turned me off OO for life when someone gave me a copy 12 years ago. It's huge, mind-numbingly boring, and I don't think I ever finished the first chapter. Don't get me wrong - I've read more 1000+ page programming books from cover to cover than I can remember, but Design Patterns just didn't float my boat. It was far too academic, and reading it was like wading through treacle. For anyone wanting a "lighter" introduction to design patterns I would recommend "Head First Design Patterns", or the excellent "Applying UML and Patterns" which I wish I'd read years ago. I realise your blog isn't about this book in particular though, and I'm looking forward to following.
Much of the advice in the book has entered into common parlance. Visitors, strategies, etc. are widely useful and still used - and really help establish a common vocabulary.
Some of these really address shortcomings in languages though. The Visitor pattern, for example, is less necessary in languages with true dynamic binding.
The one which really should be in an anti-pattern book is the Singleton pattern. I still regularly see implementations posted in various languages (one in the last 2 days in C++ in Reddit for example).
FOR YOU - may be. Life is changed so much that all those GoF you can use in toilet. Really.
Vincent, Did you missed the part where I setup the context?
"And because I know the nitpickers, let me setup the context. We are talking about building design patterns within the context of .NET application, aimed at either system software (like RavenDB) or enterprise applications"
The idea of design patterns is still relevant, I think. However just blindly ripping them from GoF and using today in any old language is not a good idea. I mainly code Ruby today and one of my favorite Ruby books is an adaption of the relevant GoF patterns to the Ruby way of thinking and coding. (http://designpatternsinruby.com).
Design Patterns are a language that designers use to describe solutions, and potential solutions. If you need to look at a book to USE a design pattern you are doing code wrong. The design pattern emerges from the code required to solve the problem in a maintainable fashion.
Also I recommend the Head First Design Patterns book as well. Much more palatable than the GoF offering.
I look forward to what you have to say.
I agree completely with the part that design patterns should be used to simplify code. I have seen many projects (and I unfortunately also implemented one - I learned my lesson) where they were used for the sake of using them and in turn turning what should be a relatively simple application into a beast.
I regularly use State, Observer, Factory and Builder. Less often the others.
GoF was right for its day. I found it a brief and concise introduction to be able to explore patterns further. I read Heads-First when it came out and found it both easy to read and informative.
I also bought the 'Design Patterns (Erich Gamma et. al.) in 2002 and found it almost unreadable.
I read that book in 1998 and found it to be garbage. Since then my opinion of it has only gotten worse.
Just wrote a WinRT app using MvvM. About half way through I realized I could delete about half of the code moving my vm to the code behind. Goodby reverse command. Goodby reference to the dispatcher for wcf stuff. Goodby overcomplicated abstraction. Hello reality.
I think that design patterns are usefull even in the .NET/HTTP/Multithreading/Mobile time like now. Widespread software requires a good designed (and robust) business logic and in this field design patters can help.
At least.....I agree with Q: the QoF book is unreadable! Try this one: "Head first Design Pattern" (http://shop.oreilly.com/product/9780596007126.do), surely an easier book ;-)
I'm pretty sure when I was in college we used that exact same book just like the 5th edition instead. That class, "Software Architecture" was one of only maybe 4 classes that I use every day in software development.
To anyone that says patterns are worthless or similar, I'm glad I'm not on your software team. And if you were on mine, i'd probably fire you.
Going to a book and picking out random patterns to build software does not make sense. But you need to understand these building blocks, and when each one is needed. At this point, alot of the patterns have been enshrined into packages that are highly specialized versions of them, but to not understand why they are that and what you're using. Well that's like running with scissors in the dark, it's not a question of if you'll trip over something only a question of a when and whether the scissors are going into your eye or not.
Comment preview