What do you consider to be the essential design patterns? And do you use them? [closed]

Question

It seems to me that programmers have an increasingly uphill task of staying up-to-date.

In my efforts to improve my programming ability, I am in search of the essential design patterns that are commonly used in computing (more specifically around .net).

For example, should I bother to memorise:

• Search algorithms?
• MVC? (is it bad to use this just for the smart url's? lol)
• MVVM? (seems no point, but haven't researched it)

etc...

What are your top 5 design patterns that you commonly use day to day (not just the ones you like)?

Answer 1

Design Patterns
Far as design patterns go, I work in an environment where there are a lot of dependencies between components, so the adapter pattern comes in handy. Especially so when trying to introduce seams in the code for unit testing support. The idea there is that you set up a wrapper around a third-party (far as your code is concerned) interface that your code relies on and that wrapper is responsible for translating your code's requests into whatever the third-party API wants.

I also see Factory used where we need to provide ways to instantiate objects defined in the supporting infrastructure code from its consumers.

Architectural Patterns
Your question, however, also talks about different architectures like MVC and MVVM. I haven't used MVVM myself, but they're really two side of the more or less the same coin. It doesn't matter if you use MVC, MVVM, MVP, or anything else - separating your UI concerns from your business logic and from your data access (if any) is a good idea. I don't work on UI anymore, but when I did, I spent a fair bit of time doing just that.

(Note that ASP.NET MVC is a framework onto itself. It's making use of the MVC approach, but be careful when referring to it simply as "MVC". You can and likely will be misunderstood and people will go "what smart URLs?")

Design Principles
Other than that, I'm a big fan of the SOLID principles:

• Single Responsibility Principle - an object should only have one responsibility
• Open/Closed Principle - entities should be open for extension and closed for modification. In other words, you should be able to extend the behaviour of a class without having to modify its code.
• Liskov Substitution Principle - subclasses should be usable in place of a base class without the consumer noticing
• Interface Segregation Principle - only expose the things the client needs. Many small specialized interfaces are better than one large generic one.
• Dependency Inversion Principle - depend on abstractions, not on concretions.

I use all of them as much as possible. There are good introduction videos for each principle on Dimecasts.

And now for something a bit different...
All that being said, I think you're approaching this from the wrong direction. While only some patterns and approaches are popular, I think it's important to learn as many of them as you can regardless of their popularity. I'd definitely say that you should learn (at least at a basic level) every pattern you come across. You never know when an obscure pattern can make your life easier. You can always go into more detail and learn a pattern in-depth when you need to... but you don't know when you need to unless you know it exists at all and have a rough idea of what it's about.

Take a look at the programmer competency matrix, see where you are, and that'll give you a slightly less muddy path to overall improvement as a developer.

Answer 2

This msdn article specifically mentions design patterns in the .net framework.

For example, it mentions patterns considered essential enough to be built into the language such as observer and iterator. Observer is supported by events and delegates. Foreach is one way iterator is supported.

Another example mentioned is the decorator pattern used in the stream library. The BufferedStream class can decorate a memory stream to provide the additional behavior of reading blocks of data at a time.

The article describes a strategy pattern is used in the List when one implements a comparison algorithm and passes it to the List.Sort. I have used this occasionally.

A fifth pattern mentioned is factory method. One example is the Convert class. The Convert class has some static methods that return classes, such as Convert.ToDateTime.

Answer 3

http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 - is a good enough list. I wouldn't say that's a lot.

Picking what design pattern you are gonna remember is like picking whether you will carry a hammer or a screw driver. They don't replace each other, they complement each other.

Answer 4

Steve Smith had an excellent video podcast on dnrTV about commonly used design patterns (1hr 4mins). It covers the following common patterns:

• Singleton (called out as an anti-pattern you want to avoid)
• Strategy
• Repository
• Proxy
• Command
• Factory

I found the video to be very interesting and a great overview of the most common patterns. For a more in depth study guide for programming you may want to look at Scott Hanselman's What Great .NET Developers Ought To Know (More .NET Interview Questions) and more recent New Interview Questions for Senior Software Engineers blog posts.

Answer 5

DakotahNorth mentions it above in a comment, but to understand patterns you gotta go back to the fundamentals. You mention some nice/essential patterns in your question (MVVM, MVC, etc.), but they are built around many of the foundational patterns as described in the Gof book. Definitely the bible and the beginning of any pattern study.

Ones we use every day?

How about Observer - anytime we wire up an event or Factory - anytime you use an Ioc container or things like strategy or bridge - when relating and tying together business rules and common behaviors.

Answer 6

I would say the "most" essential off the top of my head is:

Repository (or similar data abstraction layer e.g. TableDataGateway, DAO, etc.)

WHY: Abstracting your data layer is a good thing. Even if you never plan to change out database servers or platforms, having some kind of wrapper around the base database calls (e.g. SqlCommand and friends) and returning actual business objects (as opposed to, say, returning a DataSet) makes your code cleaner and easier to follow. It is ten times easier to read something like:

IList<Customer> recentCustomers = CustomerRepository.GetRecentCustomers();
foreach (Customer customer in recentCustomers)
{
    string name = customer.Name;
    // other things here...
}

than this:

DataSet recentCustomers = SqlHelper.ExecuteDataset(sqlCommand);
if (recentCustomers.Tables[0].Rows.Count > 0) 
{ 
    for (int i = 0; i < recentCustomers.Tables[0].Rows.Count; i++) 
    { 
        string name = recentCustomers.Tables[0].Rows[i]["CustName"].ToString();
        // other stuff here...
    }
}

Even if you aren't following DDD with Entities, and Value Objects, and the DDD version of a repository (I am using the term in a more generic fashion), using a pattern like this is key to having a good design.

Answer 7

There's an argument to be made for any pattern to be a favorite.

My recent favorite is using the messaging pattern, where you keep your components highly decoupled and have them send messages to each other. This meshes well with dependency injection (as does the interface pattern).

Another recent favorite is builder pattern. In building a complex, flexible data structure, it's useful to constrain the construction, and vastly simplify the process of doing so. For example, building a constrained FlowDocument, or dynamically generating a query.

But these are only my faves because I'm working on code that employs them. I'm sure my next sub-project will use other patterns that make me smile.

Answer 8

Actually I don't use design patterns, unless it is 100% clear I need one that fits. This means I don't check for every problem: is there a design pattern? But I use it when I notice that the solution I created is (similar) to a design pattern or when I encounter a problem I don't have an answer for.

I tend to use the simpler design pattern, simply because how simpler, how more generic they can be used, these are:

• singleton
• facade (useful for interfacing to others)
• abstract factory (useful in my work since we have a lot of more or less related devices)
• observer (in C# kind of embedded)