Catalog of Design Patterns (2017)
refactoring.guru
refactoring.guru
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.
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.
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 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)
Are "just" an interface a data type can implement/obey (in languages that support higher kinded interfaces)
> a foreach method/function for iteration over data
Again, "just" an interface a data type can implement/obey.
Yes, exactly what I meant by
> the design patterns relevant in those domains are not really called "design patterns".
I was thinking of things like algebraic or categorical laws, or invariants.
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.
but it's still a pattern ? patterns aren't classes. A specific way of sequencing function calls and operators is still a pattern.
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.
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.
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").
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.
(no affiliation - I just like playing with it)