I’ll have to hold my hands up here.  My original remarks on the composite pattern was pretty much 100% wrong.  In fairness to myself, I’m not the only one to have dismissed it as being tricky and slightly special case.  (As an aside, I really don’t think Command is a starter pattern.  To be honest, I’m still not convinced I’m doing it right.)  Like the visitor pattern, we tend to associate it with dealing with trees* and such relatively obscure topics as semantic evaluation. Actually, it’s closest to the adapter pattern.  But while the adapter pattern is about jamming...

Speaking to a colleague about the Decorator pattern, I think I was unduly harsh on decorators the last time I wrote on the subject.  I'll start off by re-iterating my opinion that writing pass-through methods is for the most part a horrible waste of time and a code smell to boot.  However, there are some cases where proxy/decorator functionality is useful where there are relatively few methods you need to proxy.  Ironically, one of these is my very first post.  It employs the decorator pattern to give you a class that executes Retlang Commands, but allows you to halt processing...

Okay, so a blog isn't the ideal format to dump 7000 words worth of thoughts on the subject of a book that weighs half a kilo.  :) I used to write film reviews: each fortnight I'd knock out about ten 50 to 100 word reviews of movies on in the local area.  I learnt a basic rule of criticism: it's an awful lot easier to be nasty than nice.  I've had the same challenge here:  the better a pattern is, the harder I find to write about it.  The dry and formal style of the Gamma et al disguises this...

This is the last pattern I'm writing up, and it's one of my favourites.  The chain of responsibility pattern is a brilliant way of dealing with special cases and functional complexity, and it does it in a way that allows you to gain the advantages of hard coding without the disadvantages of inflexibility.  Here's the basic idea: you have a list of Handlers.  Each has two operations: Do I handle this message? Process the message. The original GoF statement of chain of responsibility implements the list as a linked list, hence the term "chain".  This has the...

This is actually about the state pattern. but let me talk first a bit about enums.  A big thing to think about is that "if" statements and especially "switch" statements can sometimes be a code smell.  Enums, in particular, can be a sign that something is wrong with your code. Here's an exercise to see exactly why enums are a problem: take some code you've written (not somebody else's:  other people's code is always bad...) and identify an enum that you've defined.  An enum with a large number of values is particularly promising, but even tri-states can illustrate the problem. ...

These two patterns deal with times that you've got a requirement to be able to undo work.  There's Memento, which is a pattern of limited use (if only because a lot of the classic implementations are already available for you to use), and Command, which is one of the most criminally under-used patterns in the whole book. Memento Let's deal with Memento first.  Personally, I think most of the problem with Memento is its name.  It's a checkpoint.  You store checkpoints as you're working, and you restore back to a checkpoint if something doesn't work.  A good design for a...

I'll be frank, I don't like the Visitor Pattern.  It's a hack.  It's just a way of getting around a deficiency in the language.  Basically, extending the functionality of objects is what inheritance is for.  The whole reason the visitor pattern exists is to deal with the times that this model falls down.  Proxies and the decorator pattern could also be considered object extension mechanisms, but I've already dealt with them.  Another reason I don't like it is that it relies fairly heavily on abusing function overloading, and it's extremely brittle with regards to changes in your inheritance structure. A note:...

The patterns book is 15 years old, that's about 150 in developer years.  All told, it's amazing that more of the patterns aren't out of date.  Here are some that I think could be safely retired.  Again, they're not necessarily bad ideas, it's just that they're special cases of more general principles, and I favour understanding the principles. Bridge I'll be honest, I'm not sure I get the point of the Bridge pattern.  A bridge is exemplified by the following example from finance: You have an interface for a traded instrument.  Call it IInstrument. Shares are one...

Okay, we're onto the first of what I described as the "stone cold brilliant patterns".  This particular one looks obvious, but its benefits are actually quite subtle.  There are basically only two ways of creating an object in .NET: Call new Call a function that calls new The factory pattern is basically just using the latter.  Now, this might strike you as an unnecessary level of indirection, and you might be right.  You'd be right if: The class is a pure data transfer object. The class doesn't have a complex data structure. The class has...

I guarantee, you already know these patterns.  However, the patterns terminology is useful, if only to communicate the concepts quickly. Builder An object used to build another object.  The most obvious implementation of this pattern in the framework is StringBuilder.  It can be quite useful to have a builder in cases where what you're constructing is complex and you don't need to read from the constructed object as you're going.  (If you do, just using the object's own method is often simpler.)  The Builder pattern is used in fluent interfaces to support method chaining.  In this case, the builder constructs...

These is basically patterns where you're better off avoiding them.  Seriously, just skip those parts of the book: Singleton All patterns are a trade-off.  The trade-off with singleton is reducing the number of parameters certain functions take and trading them for more static methods.  From the perspective of code agility, a every method on singleton might as well be a static method.  Not only that, but everything the singleton touches might as well be a static method.  The testing implications of the Singleton pattern are horrendous.  Steve Yegge has written far more than I intend to on the subject, so I'm...

Previously, I talked about patterns where you were unlikely to implement them yourself, since they are now considered part of the infrastructure that goes with a modern language.  The publish/subscribe model isn't quite ready to be described as infrastructure, but it's getting close.  So, here are two patterns I don't honestly think it's worth knowing.  Here, it's not so much that the patterns are bad, just that you're better off understanding and using the publish/subscribe model.  Here's how the pub/sub model works: Participants are called services. They do not communicate directly with one another, but through messages/events raised...

Some patterns are so good they become part of the way that people think about systems.  They get implemented using general solutions and then people just use them as a piece of technology.  In these cases, a modern developer is himself unlike to implement the pattern, he's much more likely to just use the libraries that implement the pattern.  I'm terming these infrastructure patterns. Proxy and Decorator A modern developer lives with proxy objects the whole time.  If you have an object X, a proxy for object X behaves is an object that exposes the same interface as X and delegates...

I'm about to give a talk on Gang of Four patterns.  I've got to admit, I'd rather have been talking about the seminal post-punk band.  For one thing, if people disagree with my opinions ("Entertainment" is genius, for the record...) they're unlikely to take it personally.  The thing is, everyone treats the book as being something akin to the Bible in the 16th century: It's incredibly important It's full of useful ideas It's hugely respected But no-one's read it And a fair number of those that do don't understand it, and take it out context....