Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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)?

share|improve this question

closed as not constructive by gnat, Matthieu, Thomas Owens Aug 20 '12 at 15:57

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

1  
Very similar question already asked GoF Design Patterns - which ones do you actually use? –  Dakotah North May 24 '11 at 16:19
3  
They are all used. Which ones you use will depend entirely on the type of software you are writing. eg A backend developer is not likely to use MVC while a GUI programmer is unlikely to use a strategy pattern. Memorizing patterns is pointless as they are not algorithms they are much more generic than that, patterns are adapted to their actual usage situation not implemented as is cut and paste style. –  Loki Astari May 24 '11 at 19:16
    
@Martin, I agree with your comment about backend developer not likely to use MVC. For a developer in a small company like myself, I tend to dip my hands in many jars. Since it is also my first programming job, I am looking for the things that would make me a better developer... patterns, standardising the way I do things. I am also keenly aware that I am not going to learn it all, so I would like to know what the community thinks are the "key" patterns. –  Stuart Blackler May 24 '11 at 20:17
add comment

8 Answers 8

up vote 8 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
+1: Many design patterns IME, only show their real power when working together. –  Steve Evers May 24 '11 at 17:42
    
Surely there are a set of patterns that pretty much every good developer uses. Example, MVC for a blog/website. –  Stuart Blackler May 24 '11 at 20:27
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
I completely agree with you in terms of readability. Out of interest, how do you "make" your DAL? Do you keep in the same library/executable or do you move it to a separate library? I want to become more standard in the way I do things as the code I write works and is pretty good, but its a pain to maintain if im honest. I think that hampers my employability as well, but I don't want to be implementing patterns for the sake of it. –  Stuart Blackler May 24 '11 at 20:09
    
I personally use a separate C# Class Library; I originally had my libraries separated by "role" (e.g. different Library projects for Repositories, Domain, Services, Infrastructure, etc.) but lately I tend to be more conscious about the notion of DLLs so I will have a library called, say, "Core" and inside of that have folders (and Namespaces) for each section instead of a full-blown DLL. –  Wayne M May 24 '11 at 20:24
add comment

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.

share|improve this answer
add comment

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)
share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.