Sure. I've implemented plenty of factories in my time. Any complex GUIs I make almost exclusively make use of the command pattern. I even throw a decorator in there sometimes. For example, in a Java project that a friend and I are developing, we have OS-specific plugins that basically act as factories. One of the functions in these plugins takes a Class<? extends JComponent> argument and returns a new instance of that class. The returned instance could have been decorated, and if it was, it was probably because we wanted to the original JComponent to behave more natively.

I mean, these are just a few patterns that I've dealt with, but for sure I've used more, including all of the ones you've listed.

*mumble*pitchforks*mumble*....

Quote:Visitor patterns

Also called foreach.

Quote:Composite patterns

Also called a class.

Quote:Iterator

Well, iterator...

Simply put - patterns offer no useful abstraction as far as "design" goes. But without exception, they increase code size by 10x.

They're big in Java and somewhat in C# IT world though, so if that's your cup of tea... But I don't see many paying jobs in those sectors anymore.

I think it depends on situation. Patterns are good for understanding a common solution to a problem and if you find yourself doing it in a "similar" way, it's generally better to use the pattern, because your intent becomes more clear and it avoids you possibly making subtle errors.

There are a handful of patterns that come up constantly during design, such as observer, template method pattern, abstract factory, command, etc... There are others that are used less frequently, but very useful in those circumstances, such as adapter, decorator, chain of responsibility, visitor, etc... Then, there are some that I almost never find useful. Flyweight and Singleton come to mind.

Ultimately, pick the right tool for the job. If you're writing good OO code you will naturally use patterns. As with anything else, there are levels of overuse and underuse, so choose wisely.

Quote:Original post by Antheus
They're big in Java and somewhat in C# IT world though, so if that's your cup of tea... But I don't see many paying jobs in those sectors anymore.

You don't see paying jobs in Java and C#?

Quote:Original post by Hodgman
If people keep implementing similar designs, it helps to attach names to these common designs so they're easier to talk about.

IMHO, it makes sense to use a language which doesn't need patterns. Patterns are boiler-plate code of trying to tack an incorrect paradigm onto a language which isn't built to support it.

And if using more idiomatic approach, then finding a compromise between natural capabilities of a language and design requirements seems reasonable. Otherwise we end up with "#include <pascal.h>".

A fully polymorphic, double-dispatched visitor implementation using interfaces may be a nice generalization of a problem. But then again, is it really warranted to go through all such complications when all that code requires is:

std::for_each(x.begin(), x.end(), visitor);

Containers storing by value are perfectly valid design in C++, and trying to express everything with a container of pointers just because sometime one might need polymorphism is redundant. And it works the other way too - C++ designs favor non-polymorphic classes, so taking that into consideration at design stage makes sense. Same for other languages.

There are grains of wisdom and experience scattered throughout the patterns book, but the book could be abbreviated to a single page, definitely not something worth mentioning more than a for and while loop. How many debates are there about how to properly model a domain using a for loop.

Quote:Original post by Telastyn

the composite pattern implies that the object contains multiple instances of its own type, re-exposing functionality. Linq Expression Trees, or most UI models are a good example.

Also known as Tree. An elementary data structure.

And if they can contain previous nodes, then they become a Graph.

Or in trivial case, where dependencies are defined at compile time, they are expressed as simply members of a class, but they can still be traversed via reflection.

Why is composite suddenly so convenient, when there are hundreds of cool properties to be said about those two structures. And you can do cool stuff, like topological sort and update the UI in parallel. And store them in-place. And serialize them, and convert the representations for faster or easier traversal. Or simpler addition or manipulation.

And of course, those can be Visited, but that also had a name long before, known as tree or graph traversal. Visitor pattern is there just to fix the language deficiencies.