In yesterday’s discussion of Gang of Four Design Patterns, I said "Never name your classes after the pattern itself."  But then someone pointed out "What about Factory classes?"  "Oh, ok, ALWAYS name classes after the pattern."  Except for Singleton or Façade, and maybe a few others.  Ok then, NEVER name after the pattern, except when you do, sometimes, and then ALWAYS name those, unless otherwise noted.

So, here’s a list of the 23 Gang of Four patterns, along with when I’d use the name of the pattern in the implementation.  Unless I didn’t want to, and then I wouldn’t.  Feel free to agree with this list, unless you don’t care to.

Creational Patterns

Abstract Factory - After consideration, I have to say that I call my factories Factory, unless they’re Repositories, Data Access Layers, DAOs, or something else.  But most of the time, Factory.  Because this would just be wrong:

public class FooCreatorMakerThingy { … }

Builder - Hmm, another noun. Guess I’d use this one too, for the same reason as Abstract Factory. Most of the time. 

Factory Method - I probably would not call my Factory Methods "GetFooFactoryMethod()" because that just looks weird.   Maybe if we verbify the noun:

public Foo FactorialMethodizeFoo() {…}

Nope, that’s still dumb.

Prototype - "Specify the kinds of objects to create using a prototypical instance…" So we don’t care that the class is a "Prototype," but we do care about the "kind of object" part.  So don’t name your prototypical classes "FooPrototype."  (Unless you just want to.)

Singleton - Somebody have a case where it makes sense to name your Singleton "Singleton"?  I can’t come up with one.  Anyway, you shouldn’t be using singletons anymore anyway. 

Structural Patterns

Adapter - Adapters are pretty much called Adapters.  Except when they’re called Wrappers.  So you can use this name too.

Bridge - I wouldn’t label a participant in a bridge pattern "FooBridge," unless I was trying to impress on an interview test or something.  And even then, that’s a bad idea.  "Ohh, look, I know a complicated design pattern!  Lookitme!"  So don’t call your bridges Bridges. 

Composite - "One of the goals of the Composite  pattern is to make clients unaware of the specific Leaf or Composite classes they’re using."  So you don’t want to point out that Composites are in play, that breaks the suspension of disbelief for your audience.  Or something.  Anyway Composites get used all over the place, if we had to label them all then it’d be FooComposite, BarComposite, TreeComposite, EverythingComposite, and what’s the fun in that.

Decorator - I think in general people don’t label their Decorators Decorators.  I’m sure there’s a counter-example to this, but all of the Stream- and Xml-handling classes I can think of don’t point out that they are Decorators.  You’d probably want to stick to more descriptive names, like ASCIIStreamReader instead of cluttering things up with ASCIIStreamDecorator.  We’re not decorating the stream (in a literal sense), we’re reading it. 

Façade - Don’t call your Façade "FooFaçade," that’s just silly.  Besides, its too much work to type that cedille into the editor if you’re using an ignorant American keyboard.

Flyweight - This is another pattern where we’re going to disguise what’s going on inside, in order to simplify the client’s usage and make better use of resources.  No reason to flaunt to the client that we’re low on resources, because that’s a personal and private matter - times are tough all over, and there’s no shame in struggling a little bit, and hey who could have predicted that the sub-prime loan market was going to … anyway, back to patterns.   Don’t call your Flyweights Flyweights, unless what you’re modeling is actually a Flyweight, and then thats OK.

Proxy - This one is standard terminology.  So Proxy’s ok.

Behavioral Patterns (or "MAN this book has a lot of pages in it..")

Chain of Responsibility - Don’t even think of naming a class ChainOfResponsibility.  Even with ReSharper, who’d want to have to type that?

Command - Another convenient noun.  Ok, you can create Commands. 

Interpreter - This is another pattern that doesn’t have one identifying class that you could label "The Interpreter."  But you might create a Façade, and call that class Interpreter.  I’m not sure if naming one pattern after another is OK or not.  Makes my head hurt. 

Iterator - Another convenient noun.  Iterate away!  Not that you’ll have to worry too much about naming classes with this pattern if you use C#, Java, C++ or pretty much any other modern language, since this pattern is built-in.

Mediator - This pattern promotes loose coupling, most of the time I’d call what it does a "Controller," or what’s being Mediated is more on a service level, so perhaps the word "Service" would end up in the name.  Can’t say I’ve ever called a class specifically "FooMediator", but I suppose I don’t have a problem with it if you want to do that.

Memento - This pattern captures and externalizes an object’s state.  So I think I’d call something like it "State" before "Memento," since it’s fewer letters to type.  Besides, I had to see that movie twice before I really appreciated it. 

Ok, that was just lame, sorry.

Observer - Oh, you mean like an Event?  Or more like a delegate? 

State - I’d call my implementation of this pattern "Memento," just to confuse you.  That’s just how I roll.

Strategy - This is another pattern that it seems like we use all the time, without having to give it a fancy Ivory Tower name.  As someone pointed out (sorry I lost the reference to who said that) Microsoft calls all their Strategy implementations Providers now anyway.  Rather than label something a "Strategy" I’d probably just say what the thing does: "CryptographicProvider."

Template Method - Yet another pattern where there’s no obvious place to hang the name off of, so don’t try to force it in there and impress your coworkers with how smart you are.  We know, you’re a Design Pattern God, no need to brag about it.

Visitor - Hmm, not sure where I stand on this one.  I have used this pattern where I’ve named a visitor "SqlGeneratingVisitor."  But maybe that was a mistake?  So how about we just declare this one "Free Parking," and you can do what you want.

So, there you go.  A bunch of design patterns, summarized into one neat page.  Now you’re ready to ace that interview! 

disclaimer: I make no guarantees that any or all of the information will not harm you in a technical interview, and if repeating this to an interview board gets your removed from the building by security, its not my fault.  This information comes without warantees or conditions of any kind, and you probably shouldn’t have bothered reading it..

Share This

Filed under: Esoterica