5 ms·
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 comp
by hyfgfh 9mo ago
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-knowledge' era... I don't know how we can keep things up at this pace.
- prodigycorp 9mo agoWhat's interesting about frontend is that there are two ways to evaluate it: by how it looks and how it's written. It definitely biases how people evaluate llms. Many cite Claude as their favorite llm for generating frontend code, but I suspect that many people prefer it because the output is prettier, rather than better composed.
- davidkunz 9mo ago> It's in Java, but the lessons can be applied in every language. I can only discourage anyone from applying Java patterns all over the place. One example in JavaScript: There was a functionality that required some parameters with default values. The plain solution would have been: function doStuff({ x = 9, y = 10 } = {}) { ... } Instead, they created a class with private properties and used the builder pattern to set them. Totally unnecessary.
- Kwpolska 9mo agoI'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.
- microtherion 9mo agoI'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.
- Kwpolska 9mo agoHere is an example of the Builder pattern that illustrates my point: https://www.baeldung.com/java-builder-pattern#bd-classic-builder-pattern https://www.baeldung.com/java-builder-pattern#bd-classic-bui... Let’s remove the category argument and you get this: Post post = new Post.Builder() .title("Java Builder Pattern") .text("Explaining how to implement the Builder Pattern in Java") .build(); This builder is a more readable alternative to this: Post post = new Post("Java Builder Pattern", "Explaining how to implement the Builder Pattern in Java", null); But if Java supported named arguments and default values (the default would be null), this could just be: Post post = new Post(title: "Java Builder Pattern", text: "Explaining how to implement the Builder Pattern in Java");
- vips7L 9mo agoFunny part is that Java does have named parameters, but only for annotations!
- signal11 9mo agoDesign patterns are language independent, but a lot of the ones many Java devs focus on are a bit meh. In a world with only assembly language, for instance, it’s a bit like making a big deal about a “guarded repetition” pattern (aka a while loop). Eg in Lisps, a lot of patterns become one-liners. At that point these patterns become a “can you write decent Lisp” question[1]. [1] https://mishadoff.com/blog/clojure-design-patterns/ https://mishadoff.com/blog/clojure-design-patterns/