Jump to content
  • Advertisement
Sign in to follow this  
Concentrate

Do you guys use patterns?

This topic is 3016 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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 this post


Link to post
Share on other sites
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<? 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 this post


Link to post
Share on other sites
*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 this post


Link to post
Share on other sites
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 this post


Link to post
Share on other sites
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#?

Share this post


Link to post
Share on other sites
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 this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!