Do you use design patterns?

Question

What\'s the penetration of design patterns in the real world? Do you use them in your day to day job - discussing how and where to apply them with your coworkers - or do the

Answer 1

Yes, Factory, Chain of Responsibility, Command, Proxy, Visitor, and Observer, among others, are in use in a codebase I work with daily. As far as MVC goes, this site seems to use it quite well, and the devs couldn't say enough good things in the latest podcast.

Answer 2

Yes. Design patterns can be wonderful when used appropriately. As you mentioned, I am now using Model-View-Controller (MVC) for all of my web projects. It is a very common pattern in the web space which makes server-side code much cleaner and well-organized.

Beyond that, here are some other patterns that may be useful:

• MVVM (Model-View-ViewModel): a similar pattern to MVC; used for WPF and Silverlight applications.

• Composition: Great for when you need to use a hierarchy of objects.

• Singleton: More elegant than using globals for storing items that truly need a single instance. As you mentioned, a simple pattern but it does have its uses.

It is worth noting a design pattern can also highlight a lack of language features and/or deficiencies in a language. For example, iterators are now built in as part of newer languages.

In general design patterns are quite useful but you should not use them everywhere; just where they are a good fit for your needs.

Answer 3

Yes, design patterns are largely used in the real world - and daily by many of the people I work with.

In my opinion the biggest value provided by design patterns is that they provide a universal, high level language for you to convey software design to other programmers.

For instance instead of describing your new class as a "utility that creates one of several other classes based on some combination of input criteria", you can simply say it's an "abstract factory" and everyone instantly understands what you're talking about.

Answer 4

Yes.

We are even using them in my current job: Mainframe coding with COBOL and PL/I.

So far I have seen Adaptor, Visitor, Facade, Module, Observer and something very close to Composite and Iterator. Due to the nature of the languages it's mostly strutural patterns that are used. Also, I'm not always sure that the people who use them do so conciously :D

Answer 5

Any large program that is well written will use design patterns, even if they aren't named or recognized as such. That's what design patterns are, designs that repeatedly and naturally occur. If you're interfacing with an ugly API, you'll likely find yourself implementing a Facade to clean it up. If you've got messaging between components that you need to decouple, you may find yourself using Observer. If you've got several interchangeable algorithms, you might end up using Strategy.

It's worth knowing the design patterns because you're more likely to recognize them and then converge on a clean solution more quickly. However, even if you don't know them at all, you'll end up creating them eventually (if you are a decent programmer).

And of course, if you are using a modern language, you'll probably be forced to use them for some things, because they're baked into the standard libraries.

Answer 6

I find the MVC pattern really useful to isolate your model logic, which can than be reused or worked on without too much trouble. It also helps de-coupling your classes and makes unit testing easier. I wrote about it recently (yes, shameless plug here...)

Also, I've recently used a factory pattern from a base class to generate and return the proper DataContext class that I needed on the fly, using LINQ.

Bridges are used when trying when trying to glue together two different technologies (like Cocoa and Ruby on the Mac, for example)

I find, however, that whenever I implement a pattern, it's because I knew about it before hand. Some extra thought generally goes into it as I find I must modify the original pattern slightly to accommodate my needs.

You just need to be careful not to become and architecture astronaut!