Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Patterns.dev

patterns.dev

Post reply on HN
Print view View original

71–80 of 158 posts

Re: Patterns.dev

#71

Post by microtherion »

viraptor wrote: post #62
socketcluster wrote: post #44

I find that the more senior you become, the less you rely on software design patterns. Juniors often think that learning design patterns is some kind of career hack which will allow them to skip ahead a decade of experience... There is some utility in many design patterns but the problem is that juniors often miss the nuance and the motivation behind the patterns and they tend to misuse them; often creating more comp…

I wouldn't say it's cringe. A factory is a factory. Calling it that in the code may not be the best idea, but having the shared vocabulary is nice. Basically, patterns work well when they're descriptive rather than prescriptive. There are two cases that are unique though: state machines and visitors are so much things on their own, that you'll use those names almost every time you run into the pattern.

> A factory is a factory.

Yes, but what about factory factories? https://factoryfactoryfactory.net

Re: Patterns.dev

#72

Post by microtherion »

Kwpolska wrote: post #54
hyfgfh wrote: post #48

Earlier quoted context omitted.

Agreed! The problem is that some 'seniors' never cared to learn patterns in the first place. That’s a huge problem for frontend, where we have increasingly complex architectures and people with very little experience with design. Even some principles aren't known. I always recommend the book Head First: Design Patterns. It's in Java, but the lessons can be applied in every language. Unfortunately, we are in a 'post-k…

I've read that book, and it felt very childish and condescending. Design patterns cannot be applied in every language. While some patterns are applicable everywhere, many of them provide replacements for missing language features. For example, the Builder pattern is not very useful in languages with default parameters and named arguments.

I'm not sure what Builder would have to do with default parameters and named arguments.

Builder is extremely useful to pair with a parser, e.g. SAX. The parser parses the input, and the builder then decides what to do with it.

Re: Patterns.dev

#73

Post by [deleted] »

dkersten wrote: post #64

I hate that singleton is first. Singletons are just globals with extra steps, and have all the same problems globals have, just people (especially juniors) think they somehow are better. In reality they’re worse because they conflate global access with enforced single instance. You almost never need to enforce a single instance. If you only want one of something, then create only one. Don’t enforce it unless it’s cri…

[deleted]

Re: Patterns.dev

#75

Post by dimaor »

nl wrote: post #12

Does anyone remember the Yahoo design patterns library? It was mostly for UX pattern (eg: ways to "Rate an object") and it was really good. Almost 20 years ago.. damn. https://creativecommons.org/2006/02/14/yahoodesignpatternlib... https://web.archive.org/web/20060221111812/http://developer.... They had a great comparison of the different behaviors leaderboards could encourage in users.

for some reason I remember him being related to YUI, but I learned JS from Douglas Crockford, one of the best lectures from the old days of JS.

Re: Patterns.dev

#76

Post by Jaxan »

socketcluster wrote: post #44

I find that the more senior you become, the less you rely on software design patterns. Juniors often think that learning design patterns is some kind of career hack which will allow them to skip ahead a decade of experience... There is some utility in many design patterns but the problem is that juniors often miss the nuance and the motivation behind the patterns and they tend to misuse them; often creating more comp…

> Very useful pattern but I don't believe it has a name.

This is an instance of “use the right data structure for the job”. To me it has little to do with architectural design (where design patterns live), but it has to do with algorithmic design.

Re: Patterns.dev

#77

Post by elktown »

8cvor6j844qw_d6 wrote: post #6

Looks great, time to add it to my bookmarks. Anyone has other sites like these to share? - Domain-driven design, design patterns, and antipatterns https://deviq.com/ - Refactoring and Design Patterns https://refactoring.guru/ - Standard Patterns in Choice-Based Games https://heterogenoustasks.wordpress.com/2015/01/26/standard-...

Here be dragons. People trying to pattern-match their problems to design patterns can waste a lot of time and effort over many years. Use responsibly.

Re: Patterns.dev

#78

Post by songodongo »

HumanOstrich wrote: post #3

I was glancing around and landed on the page for the flyweight pattern.[1] It looks like `addBook` is using the spread operator, which always creates a shallow copy of the book instance properties, thus nullifying any benefits of the flyweight pattern. It also attaches extra arbitrary properties, but still assigns the result to a `book` variable. I don't think this is a great example. [1]: https://www.patterns.dev/va…

Good to know I wasn’t the only one thinking “wait a second…” when reading that one and seeing the spread operator being used.

Re: Patterns.dev

#79

Post by emaro »

Design patterns can be really helpful. In my previous job I worked on enterprise .NET applications. It made sense to use common patterns, because most applications were big and the patterns made it easier to understand unfamiliar code, within an application but also across different teams and applications. New projects looked familiar, because the same style and the same patterns were used.

Now I'm working on an old (+10 years) JS application. Similar patterns were implemented, but in this case it's not helpful at all. The code looks very corporate and Java EE style, with a ton of getters and setters (`getName() {}`, not `get name() {}`, factories, facades, adapters, etc, etc. It's usually completely unclear what the benefit of the pattern is, and code is more complicated, for instance because creating new instances of business objects is split into `Object.build` which calls `new Object`, with no guidelines at all what part of the initialization should be in `build` and what should be in the constructor.

The gist of my comment is that patterns can be useful, but usually they're overused and if you implement one without understanding why and without benefiting from faster understanding the code because the pattern is applied consistently over multiple instances, the result is worse than just implementing what you need in a readable way (YAGNI).

Re: Patterns.dev

#80

Post by Yokohiii »

palata wrote: post #57
socketcluster wrote: post #44

I find that the more senior you become, the less you rely on software design patterns. Juniors often think that learning design patterns is some kind of career hack which will allow them to skip ahead a decade of experience... There is some utility in many design patterns but the problem is that juniors often miss the nuance and the motivation behind the patterns and they tend to misuse them; often creating more comp…

I see it as a common vocabulary to talk about tools. It's simpler to say "I made a singleton" than to describe it. Just like we have words for a nail, a screw, a hammer. If you had to say "I used a tool that I find works well with nails", that would be annoying and ambiguous. Now of course, if you quickly screwed something with your swiss-army knife and a junior came and told you that this is wrong, because you shoul…

You point out the cultural issue that this creates and sweep it under the rug, violently.

The thought model complicates the process of writing new code, "what pattern do i need here?" and the perception of existing code, "oh this is pattern X, why isn't that communicated clearly?". The truth is that design patterns are at best stagnant in quality and quantity over time (GoF is over 30 years old!), but the quantity and quality of problems is infinite.

I've thought in patterns quite some time in my early career. With my colleague back then everything was an pattern and we were kind of in sync with that approach. But it quickly falls apart if you have peers that are less try hard on it. You can spend days, weeks, months to study design patterns and then have to explain it to someone in 5 minutes that simply doesn't care. I can't blame anyone to not care, so that has to be accounted for.

I think the common language argument is tempting, but also too stressed. Good and useful programming knowledge is bound by reality. An integer is a indisputable thing that is always useful. A "singleton" is just a fancy rephrasing of "global state".

Post reply on HN