Most of us have already used the casual patterns such as MVC, strategy, etc.
But there must be some unusual solutions to unusual problems, and I'd like to hear about it.
This seems to be a duplicate of http://stackoverflow.com/questions/105049/what-are-the-best-design-patterns-books-you-have-read
UPDATE: I misread the question. So this isn't a duplicate. Apologies. :)
No, that's about DP books and this thread is about the particular patterns.
Interpreter and Flyweight comes to mind from the Gang of 4 book.
I consider Bridge and Mediator powerful and deep patterns in the sw developer's toolbox.
It's more of an anti-pattern, but I've seen what I call the "Keep it all in one place" pattern. It was a large application, where all variables that were not local, for every class, EVERY class, were stored in a single class called P (for parameters). As an aside, all static variables were kept in a class called... wait for it... S.
Anyway, some how, this project grew quite large, and all of a sudden, nothing worked. (I got hired around this time). Amazingly, the program didn't crash, it just had tons of side effects that made the application run screwy. As you can imagine, multiple threads, all accessing P and modifying variables, with no locks or synchronization in place.
I tell you, it was truly a sight to behold.
The company opened a new office and hired 3 people to staff it, me being one of them. We weree given the program and told to fix it. We spent days sitting around just slapping our forheads. I have a permenent palm print on my face now.
Other funnies... variable named "fudgeFactor". Still don't know what that did.
Method to get next ascii character...
char getNextChar(char previous) {
switch (previous)
case 'a': return b;
case 'b': return c;
...
case 'z': return a;
}
Anyway, that's my funny pattern... with some extra side funny thrown in.
Visitor stuck me the first time when working on a graph-heavy program, as a very elegant way to do operations on complex structures.
besides mvc (which isn't a pattenr per se), this is the "king of patterns" in regards to its complexity and potential to solve problems.
The Fluent Interface by Fowler is quite an interesting pattern. I've always had a soft spot for Abstract Factories, Strategies, and the State Pattern too.
If I may, I recently codified a "pattern" that I call the Friend Class Pattern that some might find interesting or useful for restricting the visibility of private field accessors in languages that don't have C++-style friend classes.
The most interesting design pattern you will ever meet is one that you have created yourself, for obvious reasons.
That's not to say that it will be the best design pattern, just the most interesting.
I never saw the point of the Visitor pattern until I had to manipulate Java bytecode directly using the ASM library. It was amazing how much the pattern simplified what would otherwise have been a really complex task.
The pattern is also used in most Java IDE's when you want to write your own refactoring plugin. You provide a Visitor object and it is passed around the AST to make whatever changes are required.
Crash Only Software: http://www.usenix.org/events/hotos03/tech/full_papers/candea/candea_html/ Abstract
Crash-only programs crash safely and recover quickly. There is only one way to stop such software -- by crashing it -- and only one way to bring it up -- by initiating recovery. Crash-only systems are built from crash-only components, and the use of transparent component-level retries hides intra-system component crashes from end users. In this paper we advocate a crash-only design for Internet systems, showing that it can lead to more reliable, predictable code and faster, more effective recovery. We present ideas on how to build such crash-only Internet services, taking successful techniques to their logical extreme.
For the last year I've been doing maintenance on a windows application written in LANSA where the focus is managed by having all controls set to tabStop = false except for two hidden buttons (PrevFocus and NextFocus). When a form is loaded, the focus is set to a field, and the name of that field is stored in a tracking variable (apptly named 'FocusField'). When the user tabs (or shift-tabs) to change focus, the GotFocus event of the appropriate button is run. Inside that function is a case statement (select case FocusField). Based on the currently focused field, validation logic is run and, possibly, the focus changes to another field.
The GotFocus events for most controls look at what the current value of FocusField is and then call a LostFocus function that does that same case statement work for FocusField so that the previously focused field will get validated.
As you can probably guess, this makes it impossible to separate the UI from the logic, and an unbelievable chore to maintain. Re-writing these forms to use a simple Validate method that validates ALL the inputs and letting the normal tabbing properties (TabOrder, TabStop, etc) do their magic has usually resulted in 50% reduction in code and vastly more reliable forms.
I have no idea where this pattern originated, though it may have been dreamed up by the RPG/green-screen programmers turned WinForms developers that wrote the application.