this post was submitted on 20 Oct 2023
9 points (90.9% liked)

Programming

17405 readers
186 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 1 year ago
MODERATORS
 

I see this often with both new and old developers, they have one way of doing a thing and when presented with a new problem they will fall back to what they are used to even if it's not the optimal solution. It will probably work if you bruteforce it into your usual patterns but sometimes, a different approach is much easier to implement and maintain as long as you are willing to learn it, and more importantly - know it exists in the first place.

On a less abstract level, I guess my question is - how would I go around learning about different design patterns and approaches to problem solving if I don't know about their existence in the first place? Is it just a matter of proactive learning and I should know all of them in advance, as well as their uses?

Let's for example say I need to create a system for inserting a large amount of data from files into the db, or you need to create some service with many scheduled tasks, or an user authentication system. Before you sit down and start developing those the way you usually do, what kind of steps could you take to learn a potentially better way of doing it?

you are viewing a single comment's thread
view the rest of the comments
[โ€“] [email protected] 1 points 1 year ago (1 children)

Maybe I'm using the word pattern wrong but I meant like builder, factory or visitor pattern, but on a more wide scale also stuff like dependency injection / IoC - basically "techniques" that are not bound to a specific language but rather provide a design by which some things can be accomplished better. Afaik those are not related to specific languages

[โ€“] [email protected] 0 points 1 year ago

I would call those language-specific. While they are useful in more than one language, they are also replaced by language features in many languages.

  • Builder pattern can be simplified with kwargs (Python, C#) or argument objects (JS, C++).
  • Factory pattern can be simplified with first-class types (Lisp, Haskell).
  • Visitor pattern is similarly simplified by first-class functions (supported by most languages nowadays).
  • Dependency injection of concept X is generally simplified by first-class X. I think the least widely supported is dependency injection of effects (Koka).