10 years ago, in my list of "Nice things to learn and do to be serious about software engineering", Design Patterns was probably in the top 3. Nowadays, it doesn't even make it to the top 20. I can't really say why, though. I guess 10 years ago I was really junior and I didn't know tons of stuff... It's not that nowadays I know all the patterns, but it's just that the noun "design pattern" already evokes in me red flags.
A lot of times partially good ideas get overblown and create "fad shrapnel" where they explode on the scene and get overused and overhyped by the naïve, Resume Oriented Programmers[1], or book/article pushers.
One of the most frustrating things about Design Patterns is that it's never been clear when to use them and when not to. Making a good choice often requires intimately knowing the domain, and guessing the future well. Most us are lousy at predicting the future. If we were any good at it, we'd be golfing with Warren Buffett instead of figuring out why our Java won't compile on a Monday.
Their Visitor Pattern scenario is crying out for a database, by the way. Don't reinvent a database in app code: you get spaghetti objects.
Apply YAGNI and KISS, and only add design patterns if there is a clear and present need.
[1] Buzzword collectors looking for their next gig and (mis) using your business as their personal college or R&D lab.
> only add design patterns if there is a clear and present need.
I know what you mean, don't copy the designs explained in design patterns books unless it makes sense.
But to be clear on the wording, you don't really "add design patterns" ever. Your code is your design, designed by you. If there are recurring "patterns" in your code-solutions and recurring in the sense that others use them too and have documented them, then you can "see patterns" in your code. In other words you can recognize some patterns, some recurring structures in your code.
Design Patterns are abstract entities you can not move them around. You can only describe them. Therefore people have tried to write books about them. You can only add code to your source-files, not "patterns". Can you see recurring patterns in your code? Maybe. If you think those recurring patterns are good enough to communicate to others then you may want to write a book or even just an email or HN post about them.
The problem I see with the existing design patterns books is that a pattern describes a great solution in a specific context. But contexts vary wildly. Part of the context is the programming language used. They too vary wildly. So I think the basic idea of Design Patterns is great, but in practice their benefit may be limited depending on the generality/applicability and quality of the patterns described, in them books.
> Their Visitor Pattern scenario is crying out for a database
How so? Where you store your data doesn’t matter to your export logic. Whether it retrieves the original data structure from memory or the database doesn’t make a difference to the visitor.
I think a partial cause for the loss of importance is due to design patterns being relatively oriented towards OOP. With the move away from OOP and towards functional programming and type theory, the term fell away because the design patterns relevant in those domains are not really called "design patterns".
I've had the same thought. I've never seen it confirmed by anyone, but to me, a lot of the original design patterns were stopgap conventions to patch shortcomings in the languages of their time (mainly early Java).
Just look at the Visitor pattern. It's a convention to expose an "accept" method that can be "visited". That's pretty much what you'd do far easier and more naturally with functional programming these days, even in Java. Going in depth, you can see the same possibilities everywhere. "Proxy" should probably be a registerable middleware, etc. etc.
Then again, I might be biased. Design Patterns already let my BS detector go bonkers 15 years ago when I encountered them first, as as academization and complication of software by self-indulgent "enterprise programmers" that I couldn't ever see any advantages to (and these days, I feel enjoyably vindicated).
Funnily enough, in this way they were quite anti-academic, as they came from original research of the "Gang of Four" and I've never seen scientific proof they actually made anything better. I stand to be corrected though.
I sort of think of design patterns as common code patterns that can’t be abstracted over. In Haskell, I think mtl-style type classes probably count. Maybe also the sort thing the lens library does where it says “any function that looks like this and obeys these laws can be used as a lens”. In Java (especially older versions), this set of things includes a lot of things that are trivial if you have lambda expressions.
Functional programming still has patterns, they are just different patterns. For example, (let loop ([arg _]) ...) in Scheme for iteration. Monads are another one. Another common one is a foreach method/function for iteration over data instead of using iterators.
Patterns being reified as language objects don't make them not-patterns. Trusty old function calls are still patterns, only reified from asm routines and procedures.
On the other hand they're really old now and, obviously, don't get that that old. So it's the kind of thing you learn once and then you'll inevitably find the use for some of them, or find them in codebases, for a very long time.
I don't know if I to smile or lament that it's basically the ones that were explained in the gang of four's Design Patterns book... Nearly, what, 30 years ago now? (now I feel really old)
Yeah, you can go too far, but I think it's a mistake to dismiss it like that.
If you are a true senior, they probably sound as simple as breathing. But I've seen projects take up months instead of days simply for them not applying some knowledge of design patterns.
>It's not that nowadays I know all the patterns, but it's just that the noun "design pattern" already evokes in me red flags.
Me too, but if you think about it for a while, then design pattern is just name for some approaches to some problems that should improve communication by making it more precise.
I suppose I'm prejudiced.. There's a whole load of "Design Patterns" books that haven't had much of an impact, when you try to read them, many of them have the author's pet idiosyncrasies or preferences in how they interpret patterns. Things like "Java/Python/C# Design patterns" are usually best avoided - especially some authors whose experience is not sufficiently deep, and they've not proven the patterns in a large # of projects.
Esp. with a language like Python, where classes are very light-weight (compared with Java, say) , I've seen authors write some dense/opaque English to describe their patterns.. When a book in my coding language makes me, an experienced developer feel dumb .. I can't be helped - either I'm dumb or the book is dumb .. either way , I've wasted good money on yet another patterns book - not again.
I like these two brilliant American aphorisms to describe OOPs.
First : Everything in its place, and a place for everything. Second : Data + Algorithms = Programs.
With Languages like Python, Go, Rust, JavaScript where functions can pretty much rule , and you employ classes where actually needed, OOPs can be summed up as above.
Java started the trend of overbearing classes bolted onto every problem ("a solution looking for a problem").
In the last years I came to the realization that - contrary to public opinion - these design pattern, SOLID principles and other concepts are transferable far beyond OOP. Not only to functional programming but also architecture and e.g. organization structure. Adapter, Strategy, Composition, ... Single responsibility, ...
I would love seeing the traditional pattern catalogue translated to functional usage and there named and rationalized. I take bets that 80% or more are valid and massively used in the FP community.
I would have called those "icons" but in any case what tool is good for making them? I have used illustrator (now switching to inkscape) but it seems like you really need some specialized skills out of reach for the common man (person).
