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

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

Explanation / Answer

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.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.