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.
Patterns.dev
21–30 of 158 posts
Re: Patterns.dev
#22Does 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.
Re: Patterns.dev
#23The ones that actually match POSD (deep modules, small interfaces, lower complexity) and work great with plain functions are: Module Pattern Factory Pattern (factory functions) Mediator / Middleware Pattern (as function pipelines) Hooks Pattern (custom hooks, generalized) Container / Presentational Pattern (implemented with function components + hooks) Everything else is either neutral, UI-only, or fights POSD (Singl…
What does POSD stand for?
Re: Patterns.dev
#24Looks 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-...
Re: Patterns.dev
#25Looks 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-...
- Java Design Patterns https://java-design-patterns.com/
Re: Patterns.dev
#26I 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…
No, the opposite: it highlights the benefits of the flyweight pattern. The shallow copy saves memory. That's the point. You have two identical books. Rather than wasting memory with a deep copy, you make a shallow copy, where all your props point to locations in memory where values are located, and then you modify whatever is different. Now your shallow copy only consumes a small bit of extra memory.
And if those props are all primitives, then you can then modify that shallow copy, and it won't affect the original.
Re: Patterns.dev
#27Looks 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-...
I’ll make a plug for aep.dev, which is a collection of API design best practices and assorted tooling
Re: Patterns.dev
#28I 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…
> which always creates a shallow copy of the book instance properties, thus nullifying any benefits of the flyweight pattern No, the opposite: it highlights the benefits of the flyweight pattern. The shallow copy saves memory. That's the point. You have two identical books. Rather than wasting memory with a deep copy, you make a shallow copy, where all your props point to locations in memory where values are located,…
> The shallow copy saves memory....
Versus not making a copy? A shallow copy of primitives still copies them and uses additional memory. Maybe there's some low-level optimization that makes it more efficient than that, but it's not relevant here. And there isn't any deep cloning happening in the example.
Might as well get rid of the complexity and instantiate a new Book class every time. And maybe stop shallow-copying class instances into new plain objects. It works for the example but has footguns.
Conveniently, there are other patterns on the site that would help you avoid creating an amalgamation of random merged class instances and objects.
The whole example is a mess.
Re: Patterns.dev
#29I tend to advocate for people to study design patterns. Not for the purpose that you will necessarily ever use most (or even any) of these exact patterns in your software, but just that you've strengthened your mental muscle for software design in general. I encounter lots of engineers who simply aren't able to think "outside the box" when building something new.
Re: Patterns.dev
#30Looks 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-...
https://learn.microsoft.com/en-us/azure/architecture/pattern...