Original Post
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?
🔒 Locked
Do you guys use patterns?
Advertisement
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 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.
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*....
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.
Quote:Also called foreach.
Visitor patterns
Quote:Also called a class.
Composite patterns
Quote:Well, iterator...
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.
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#?
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".
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.
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:Using foreach increases code size by 10x?!?!?
Original post by Antheus Quote:Also called foreach.
Visitor patterns
Simply put - patterns offer no useful abstraction as far as "design" goes. But without exception, they increase 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.
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
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.
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.
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.
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.
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)
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.
Quote:
Original post by Telastyn
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.
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.
Quote:So functionality like serialisation, or "undo" should be built into every language??
Original post by Antheus
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.
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]
Quote:
Original post by Antheus
*mumble*pitchforks*mumble*....Quote:Also called foreach.
Visitor patterns
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.
Quote:
Original post by Antheus
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.
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.
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.
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.
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.
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.
Quote:
Original post by Telastyn
I 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.
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.
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.
Quote:
Original post by jwezorek
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++?)
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.
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement