Design patterns
Years and years ago when everyone where developing desktop and client server applications there where no frameworks in place. When you started and went File -> New Project the world was open, you could rule it, do anything you wanted as all you had were a single blank unstructured file. You the developer had to structure and design the code yourself and while doing so there where common problems to solve.
Design patterns are the solutions to these common problems. After years and years of solving these common problems people started to realize that their solutions were all very similar and these became known as design patterns. The first books written on the topic was by the Gang of Four which has immortalized them in history.
There are a few design patterns that I personally love using.
Where we find ourselves today.
As technology and time has progressed I have noticed that the new windows developers coming into the field did not have a clue or understanding of design patterns and I think this is due the the era where they find themselves.
They code within a predefined framework of MVC which is a design pattern itself and they know nothing else. They don’t even known it’s a pattern. In the same manner how the introduction of .net back in the early 2000’s made developers less knowledgeable in aspects of memory management the new Visual Studios have hidden design problems from developers.
Developers from today don’t have insight into how computers work, how an application works, they don’t have to worry about frameworks, components, designs or even events. This has resulted in a weaker developer in my opinion but what it has allowed them to focus on areas that are of more importance to the the current markets.
Today people that alter templates in word press and add plugins from other companies are considered software developers as they do “develop” solutions for companies.
At my current work place we really struggle to get developers that are able to work in our more serious application. So this made me wonder. Are design patterns still relevant?
Are design patterns still relevant?
What has happened is that companies like Microsoft and Oracle has made it easier to be a developer. They are doing the thinking for us. Creating the frameworks for us, so that we can be more productive at “what we do” but what is happening is that we are doing less and less of the parts that make an application function. No longer do we need to know how things work…we simply have to accept that they do.
Tools and techniques of today have made design patterns irrelevant. Most companies do very basic web / front end projects which has resulted in the majority of developers being semi mindless drones just typing their logic within a predefined structure without thinking what happens out side the curly brackets.
“{ Put code here… }”
I always believed if you want to be a serious software developer, working on the edge of technology trying to do anything in a serious manner; you need to at least have a basic understanding of what design patterns are, where to use them and what they are used for…
Am I a dying breed for wanting to know how things work?
Areas where design patterns and architecture have remained relevant are in the distributed systems or systems with a back-end. These developers have remained more skilled and knowledgeable as they have had to deal with serious problems relating to system integration, security, and having to structure business logic within a application but even now technologies are being rolled out to make the knowledge and skills of these developers less valuable. Ever heard of containers? Docker?…
Conclusion
So what we can observe is that design patterns where at the height of importance when majority of systems where stand-alone desktop applications and when the tooling had no frameworks. When client server entered the arena Architecture became the in-thing as there were now multiple parts of an application to consider. Architecture patterns were a natural extension of design patterns. Design patterns remained important while the tools evolved to take over some of those design decisions from the developers.
Now with the cloud I believe we are observing something similar where the tools are taking over some of the architecture considerations. No longer do you have to think about how you need to structure you application, to fit into a Container you are simply forced to do it this way… I believe that this is leading to something that will be extending architecture patterns, allowing for planning and design at even higher levels.
So design patterns are not as important at coding level today as it was 20 years ago but the concepts of it is still present and evolving to deal with bigger and bigger issues. I believe it is still important to know but it makes less impact than 20 years ago.
I think design patterns are still important and relevant, especially, like you say, for developers that work on serious software.
It helps to understand and recognize design patterns when you inherit a code base and you need to understand the code that someone else wrote.
You need to somehow get in the developer’s mind, to think like he did, because he must have had a good reason for choosing a pattern, or so you hope.
I would still like to read the Gang of Four book, but I would supplement it with a newer book like Head First Design Patterns to get a fresh perspective.
Developers today aren’t required to develop patterns from scratch, but rather understand why they exist, what problems they solve and how to apply them in a wide range of problems. I’ve read somewhere that design patterns exist because languages lack features.
It’s important that developers stay up to date with newer patterns and techniques, what happens sometimes is a developer uses a pattern because that’s all he knows, but there might be a simpler pattern or language feature, which could make the code easier to understand and therefore more maintainable.
Mainstream languages like C# and JavaScript are evolving and getting new features that can replace older patterns. Languages are “borrowing” features from each other.
If you don’t understand why MVC was created, then you, as an ASP.NET developer might find it difficult to code in MVC, because the style might be foreign and contradictory to the ASP.NET style. You have to understand why MVC is favoured over ASP.NET.