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

111–120 of 158 posts

Re: Patterns.dev

#111

Post by zelphirkalt »

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.

The visitor pattern is my go to example for patterns, that you don't really need, when you have a language that has first class functions, which implies among other things, that you can pass functions as arguments, like you can pass anything else.

The magical "visitor" pattern becomes nothing more than simple callback passing or passing a function, which is one of the most natural things to do in a modern programming language.

State machines at least are useful as a conceptual thing, to find a way to think about how one solves a problem, no matter how they are ultimately implemented in the end.

Re: Patterns.dev

#112

Post by slig »

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-...

https://www.deceptive.design/

Re: Patterns.dev

#113

Post by zelphirkalt »

arethuza wrote: post #98
TINJ wrote: post #58

Earlier quoted context omitted.

> For example, I've seen people write code which relies heavily on design patterns but then that same code uses an O(n^2) nested loop to find items that are common between two arrays. There is a simple 'pattern' you can use to store the items of the first array in a Set or HashMap and then finding common items is O(n) because Set and HashMap lookups are O(1)... Very useful pattern but I don't believe it has a name. I…

If you already have Sets handy - why not use the Set Intersection? (Assuming the Set implementation has that capability).

Putting both contents (lists, arrays, whatever you have) into sets, and then calculating the intersection might be more expensive than building the intersected set right away sourcing both non-set contents, I imagine. Though it would probably be easier to read and understand. But that can be solved by naming of functions that process the 2 non-set things.

Re: Patterns.dev

#114

Post by zelphirkalt »

agumonkey wrote: post #49
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…

What about the social / communication aspect ? Having a common vocabulary of pattern may help reduce cognitive load when reading others code. Just a soft opinion because I assume it's the reason frameworks and conventions help teamwork. Less per-context custom solutions.

It really depends. If under the guise of "best practices" and "patterns" a team creates an unmaintainable, not easily extensible mess, then all this community aspect was good for exactly nothing but shoulder patting. If instead pattern are used sparingly, where they actually make sense, then sure, it can help.

We need to keep in mind, that the most composable concept in computer programming is the pure function (or maybe a mathematical "relation", if we want to abstract further). Not a mutating object. Not some constellation of objects that constitutes a pattern. Those are merely special cases.

I am currently developing a GUI application. Most of the classes in my code are classes, that are custom widgets. The GUI framework is OOP, so that is kind of infectious for the rest of the code. Still I try to keep some stuff separately as pure functions. Probably will outsource more stuff like that into completely self sufficient functions. The only pattern I have so far in the whole application, is a mediator, which I use as a way to have objects register themselves as listeners to specific events and for other objects to send these events to anyone who will listen. That way objects don't need to know, which other objects are interested in learning about some event. Could I have built in some factories and whatnot? Surely I could have, but there would have been very little, if any benefit. Even the mediator only exists, because the GUI framework does not have a way to send events that include data, so I need a way to do that. Otherwise I could even get rid of that pattern as well.

In this way pattern are useful for when you really need them, but these OOP pattern by themselves, without context, don't really have a value. No code becomes better by building in more patterns, unless the situation requires such a solution.

Re: Patterns.dev

#115

Post by gopher_space »

elktown wrote: post #77
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.

To your point, everything we do is context-sensitive and patterns are revealed by abstracting context.

Re: Patterns.dev

#116

Post by verdverm »

Is this JavaScript's take on the GOF book selections plus all the shenans, er "patterns," the ecosystem build tools require?

I was hoping for more high-level architecture based on war stories and experience. This is pretty basic stuff, which has it's value for people earlier in their journey, and does seem to have effort put in from a quick peruse

Re: Patterns.dev

#117

Post by ozim »

emaro wrote: post #79

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…

I see a lot of comments about how patterns are useless from people writing toy apps or at least ones that never had to deal with really enterprise scale stuff. So for me they are like people building a shed screaming at people building sky scrapers that no one ever needs to pour so much concrete to form a foundation.

Parent comment is not like that.

Re: Patterns.dev

#118

Post by moron4hire »

naasking wrote: post #107
layer8 wrote: post #93

Earlier quoted context omitted.

I would put it slightly differently: Patterns (including anti-patterns) happen whether you call them such or not. Any developer will sooner or later come up with patterns like Adapter or Builder or Composite or Iterator. In that sense, patterns are not invented, but discovered. The benefit of design patterns is to be able to communicate these discovered patterns, and to define agreed names for them, so that you don't…

Yes and no. Some patterns exist because the language isn't expressive enough. This is one reason why the patterns made sense in the OP's .NET programs, but made less sense in JS. JS simply doesn't require as much ceremony for some things because it's dynamically typed and reflection kind of comes for free.

I would say that reflection in JS is terrible compared to .NET. You can only just barely figure out what is in an object, but it's a hell of a time figuring out what any of those things can do. I wouldn't so much as call what JS does "reflection" any more than "making objects out of poorly implemented hashmaps."

Re: Patterns.dev

#119

Post by culi »

lelandfe wrote: post #84
culi wrote: post #19

Earlier quoted context omitted.

I posted this elsewhere in this thread: https://component.gallery/ Great meta resource for building UI components.

Design patterns and component libraries are a bit related but they're pretty different concerns ultimately.

It's more of a meta resource. Many of these design guidelines go in depth on accessibility best practices and UI patterns

Re: Patterns.dev

#120

Post by khannn »

emaro wrote: post #79

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…

People were shifted from Java to Javascript and kept the Java patterns and maybe the organization had standards requiring their use.
Post reply on HN