[HN Gopher] Catalog of Design Patterns (2017)
___________________________________________________________________
Catalog of Design Patterns (2017)
Author : charlieirish
Score : 91 points
Date : 2022-03-14 17:21 UTC (5 hours ago)
(HTM) web link (refactoring.guru)
(TXT) w3m dump (refactoring.guru)
| Zealotux wrote:
| Always coming back to that one, the visual are great to quickly
| remind me of what a given pattern aims to achieve.
| mkranjec wrote:
| Same here. I come back over and over again and always notice
| something new.
| lmarcos wrote:
| 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.
| feanaro wrote:
| 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".
| slaymaker1907 wrote:
| 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.
| akavi wrote:
| > _Monads_
|
| 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.
| [deleted]
| tester756 wrote:
| >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.
| TacticalCoder wrote:
| 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)
| tabtab wrote:
| 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 naive, 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.
| galaxyLogic wrote:
| > 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.
| macintux wrote:
| Related recent discussion: Python Design Patterns
|
| https://news.ycombinator.com/item?id=30649470
| hyuuu wrote:
| very polished site, clear presentation of the information. I am
| going to spread this around to my colleagues :)
| mrosa__ wrote:
| On topic https://youtu.be/tv-_1er1mWI
| eshack94 wrote:
| Super useful! Bookmarked this for future reference. The graphics
| help a lot to understand the intentions and use case for each
| pattern.
| isaacaggrey wrote:
| Far more arguably useful is the section on code smells, which is
| unfortunately overshadowed by the design patterns:
| https://refactoring.guru/refactoring/smells
| mrosa__ wrote:
| Actually one of the best resource on the topic
| https://youtube.com/playlist?list=PLW-6wqFEcgTpdJ1c7x0Sw8tqR...
| vjust wrote:
| 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").
| warrenm wrote:
| Those are some pretty great glyphs!
___________________________________________________________________
(page generated 2022-03-14 23:00 UTC)