# Do you guys use patterns?

## Recommended Posts

Concentrate    181
Other than the very common patterns like the Iterator, template,Composite patterns do you guys use patterns like the Visitor patterns and other types of patterns in practice?

##### Share on other sites
aryx    402
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.

##### Share on other sites
Antheus    2409
*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.

##### Share on other sites
Rydinare    487
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.

##### Share on other sites
Hyrcan    144
Quote:
 Original post by AntheusThey'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#?

##### Share on other sites
Hodgman    51223
Patterns are useful as a shared vocabulary. They're not a "play book" of ways to solve problems, instead you should just solve the problem however it's appropriate.
Patterns come in handy afterwards, so instead of saying "This class has a virtual function that takes a callback object so you can add new functionality without changing the interface", you can just say "it's kind of like the visitor pattern".
Quote:
Original post by Antheus
Quote:
 Visitor patterns
Also called foreach.
Simply put - patterns offer no useful abstraction as far as "design" goes. But without exception, they increase code size by 10x.
Using foreach increases code size by 10x?!?!?

The whole point of patterns is that they're solutions that people constantly, and independently arrive at. I'd written a whole bunch of ad-hoc implementations of the factory pattern before I'd ever heard the phrase "design pattern".
That's why they're a "pattern" ;)
If people keep implementing similar designs, it helps to attach names to these common designs so they're easier to talk about.

##### Share on other sites
Antheus    2409
Quote:
 Original post by HodgmanIf 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.

##### Share on other sites
Telastyn    3777
I agree with Hodgman, they're very useful as a communication mechanism for developers. I spent a few years diddling around with programming only to re-discover common patterns. Even as relatively inexperienced as I was, it was pretty evident how much better some of the patterns are than other designs.

But yes, I implement design patterns all the time; except for the singleton.

And I'd disagree that the composite pattern is simply a class; 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.

##### Share on other sites
Antheus    2409
Quote:
 Original post by Telastynthe 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.

##### Share on other sites
Telastyn    3777
Sure, and then you get to implement actual behavior to make your program do something more than store ordered data. That is rather the point of design patterns, to provide a similar taxonomy to behavior as data structures have for storage. (edit: albeit with a far less scientifically defensible position)

##### Share on other sites
ARC inc    100
Every programmer uses some form of patterns whether or not they know it you can sometimes tell who has programed a line of code how it is set up most programmers have a signature pattern I think it's more along the lines of what they know an how well they know it.

##### Share on other sites
Antheus    2409
Quote:
 Original post by TelastynSure, and then you get to implement actual behavior to make your program do something more than store ordered data. That is rather the point of design patterns, to provide a similar taxonomy to behavior as data structures have for storage.

Unless dealing with people who have never come close to anything CS related - why is it easier to talk about Composite pattern and applying Visitor, than it is about traversing a tree?

Especially since patterns are covered by one book written by IT outsourcing experts, while the CS terminology is covered by 40 years of research by people who laid the foundation of computing.

But yes, they discovered that trees, graphs and lists, as well as iteration over them is frequently used in software design. And that there are language quirks to work around.

##### Share on other sites
Hodgman    51223
Quote:
 Original post by AntheusIMHO, 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.
So functionality like serialisation, or "undo" should be built into every language??
No.

So when building a game-level-loader, and realising that C++ requires me to implement a factory myself, I should switch to a language that has a built in factory?
No.

An "undo" system is a high-level application feature, which when implemented, could likely be similar to umpteen other implementations of the "command pattern". How does this signal a deficiency of a language?
What's wrong with giving the common name "factory" to a class that instantiates objects? What's wrong with shared vocabulary?

[Edited by - Hodgman on March 11, 2010 10:49:19 PM]

##### Share on other sites
cache_hit    614
Quote:
Original post by Antheus
*mumble*pitchforks*mumble*....

Quote:
 Visitor patterns
Also called foreach.

Err.. It's been a long day, but I don't get it. How are visitor and foreach related? If anything iterator is more like foreach.

##### Share on other sites
theOcelot    498
Quote:
 Original post by AntheusIMHO, 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.

That's not always true. The mediator pattern is just a way of describing a certain arrangement that allows objects to talk to each other. It's hard to imagine a language that wouldn't require you to write an Adaptor at some point, even if it took the form of some static mapping between interfaces.

Design patterns were never, as far as I can tell, meant to be more than a vocabulary for describing recurring structures in code. That some of them can be implemented much more succinctly, even trivially, in some languages than others is not really a strike against them.

##### Share on other sites
frob    44904
This reminds me of another recent thread, asking about when to use use data structures in programs.

They are simply common programming idioms. They've just been given common names so we can talk about them.

Just like named data structures and algorithms, patterns are named so we can study, reuse and take advantage of them.

We learn data structures like "linked list" and "binary tree". We learn algorithms like "quicksort", "Dijkstra's algorithm", or "A*". And we learn patterns like "factory methods", "visitors", and "command pattern".

That's really it. There is nothing fancy about it. If you learn it you will discover that your code uses patterns, even if you didn't intend to.

##### Share on other sites
iMalc    2466
Whenever I study design patterns I simply come to realise that they're just things I use every day without necessarily being able to put a name to them.

In fact I find it more useful to study anti-patterns so as to avoid them, rather than to study design patterns to simply put a name to techniques I've already discovered throughout the course of my programming career.

##### Share on other sites
rubicondev    296
Quote:
 Original post by TelastynI agree with Hodgman, they're very useful as a communication mechanism for developers...

I've been a professional game programmer for over 20 years, and if someone looked at my code and said "ah, I see you're using the blah pattern", I'd just have to nod and dribble.

Terminology is only useful if everyone knows it. I don't and see no reason to learn. I'm sure I use a lot of recogniseable patterns in my dev, but I'd have to take other peoples words for it. I just write game code.

I guess what I'm getting at is that if you read a book or do a course on this stuff then I guess it has use in opening your eyes to ways to solve particular problems, but stay right there with it. When it comes to start designing code, do what's needed for your game, not for your pattern book.

##### Share on other sites
jwezorek    2663
I've never really gotten design patterns. Terminology is only useful if it is providing greater specificity than ordinary language more succinctly. I don't see design patterns doing this. It's succinct to call some class X an adaptor, say, but it isn't particularly useful. It is less succinct to say that "Class X wraps the old library and exposes the interface that the new version of the software expects" but at least that is actually saying something about class X.

Also the whole subject seems a little confused in that in some cases patterns seem to be sort of common themes in how algorithms interact with data structures; in other cases they seem to be the data structures themselves (e.g. the composite), and in other cases they seem to be styles of programming (e.g. wikipedia lists RAII as a design pattern. Is RAII even meaningful in languages besides C++?)

Anyway, if other people find the terminology useful more power to them, but personally it all seems like a lot of hot air to me, sort of like an academic fad.

##### Share on other sites
Red Ant    471
Quote:
 Original post by jwezorekAlso the whole subject seems a little confused in that in some cases patterns seem to be sort of common themes in how algorithms interact with data structures; in other cases they seem to be the data structures themselves (e.g. the composite), and in other cases they seem to be styles of programming (e.g. wikipedia lists RAII as a design pattern. Is RAII even meaningful in languages besides C++?)

Why yes, of course it is! All three languages I commonly use (C++, Python, Tcl with the incrTcl extension) have RAII ... context managers in Python, the itcl::local command in Tcl. I'm sure other languages offer support for RAII as well. Personally, I consider any language that doesn't broken, which is the main reason I've never really gotten into Java.

##### Share on other sites
leet bix    116
I'm not sure if anyone is mentioned this yet because I don't have the time to read all the replies, but there's a reason they are called patterns... It's not like someone sat down one day and said "Ok, I'm going to write a proxy pattern", they come up often enough in general programming that they can be named. You shouldn't approach a problem trying to implement a particular pattern unless that is your specific goal.

##### Share on other sites
alvaro    21246
I sort of like the idea of identifying common patterns in the way people build programs. I read a couple of Christopher Alexander's books on patterns for architecture and I found them eye opening, although a bit repetitive. Unfortunately, I didn't find the book by the Gang of Four nearly as inspiring.

The problem is that I don't recognize a lot of the patterns in the book, because that's not how I program. I suspect part of the reason is that to me programming is not primarily about making GUIs.

The only pattern that I find useful in my communication with my colleagues is the factory pattern. That's something we do use with certain frequency. Actually, before anybody in the office knew about software patterns, we already had a name for them ("library"). But it's good to have a standardize name and I think "factory" is actually a better name.

##### Share on other sites
Telastyn    3777
Quote:
 It's succinct to call some class X an adaptor, say, but it isn't particularly useful. It is less succinct to say that "Class X wraps the old library and exposes the interface that the new version of the software expects" but at least that is actually saying something about class X.

I dunno, I really don't see any difference.

##### Share on other sites
Rydinare    487
Quote:
 Original post by alvaroI sort of like the idea of identifying common patterns in the way people build programs. I read a couple of Christopher Alexander's books on patterns for architecture and I found them eye opening, although a bit repetitive. Unfortunately, I didn't find the book by the Gang of Four nearly as inspiring.The problem is that I don't recognize a lot of the patterns in the book, because that's not how I program. I suspect part of the reason is that to me programming is not primarily about making GUIs.The only pattern that I find useful in my communication with my colleagues is the factory pattern. That's something we do use with certain frequency. Actually, before anybody in the office knew about software patterns, we already had a name for them ("library"). But it's good to have a standardize name and I think "factory" is actually a better name.

I'm not sure if I'm reading you right, but are you suggesting that design patterns are only useful in GUI development? I wasn't sure if you meant to suggest this, but if so, I highly disagree. GUIs may be used as frequent examples, because there's often less of a learning curve in describing it.

Also, the fact that you don't recognize the patterns means that there's a learning opportunity. However, read it knowing that for some of them there are newer mechanisms which can accomplish the same goals (e.g.: signals/slots instead of the observer pattern).

##### Share on other sites
swiftcoder    18426
Quote:
Original post by Red Ant
Quote:
 Is RAII even meaningful in languages besides C++?)
Why yes, of course it is! All three languages I commonly use (C++, Python, Tcl with the incrTcl extension) have RAII
Every language I am aware of that claims support for RAII, supports only a weak, limited form of it, by comparison to C++.

## Create an account or sign in to comment

You need to be a member in order to leave a comment

## Create an account

Sign up for a new account in our community. It's easy!

Register a new account