I'm very new to the language but i did not found any resources about this topic.
I'm looking for resources about modern design patterns in Rust.
Rust ist quite new but i want to elaborate whether there are already established patterns in the language.
Do you think it's a good practice to translate established patterns one-to-one into Rust?
For example like a factory, adapter etc. pattern.
I found an old repository (Design Patterns in Rust) with implemented patterns. But it seems like the author does not update it anymore.
The gang of four's design patterns mostly exist to bypass limitations or to serve as guide for programming languages like Java. You shouldn't try to use them in all languages, and especially not in Rust.
Rust could have its own patterns, but I don't think anyone wrote anything about this yet.
maybe we should start a special thread and start collecting those. We already got the "What’s everyone working on this week?" threads. This could be made into a chapter in the book or a special purpose repo later on.
It would be neat to compare notes with patterns we've come up in our Rust projects I've been contemplating how using the Into trait at API boundaries with some kind of struct versioning would work out in the wild.
On a more general note, I think people should stop trying to use design patterns and concentrate on writing a code that will solve the specific problem. I think patterns are good knowledge if it only makes you write better specific code. I met a teacher at university who thought – I guess he still thinks – that, in a perfect world, we wouldn’t write any specific code and just glue design pattern code coming from libraries.
This is all wrong. What does even modern design patterns mean in Rust? Rust is modern enough to write fast, robust and flexible code without having to cope with academic patterns that will confuse your team mates – e.g. the Visitor, the Singleton or worse, the Decorator. I think it’s good to know how to solve each of these specific problems, and trust me, you don’t need design patterns for that.
For instance, let’s take the Listener / Observer one. It makes you build several types / hierarchies in order to achieve… reactiveness. With a closure, a single closure, you can have the same behavior, with less overhead, less code to write and a more idiomatic way to go – look at how the implemented listeners are just closures.
However, you should have a look into the iterator concept, which is extensively used in Rust, as long as functional programming for what is called iterator adapters in Rust.
Pattern are a way to solve very specific recurrent problems. Giving them a consistent name will not confuse team mates but instead make the intent clear.
But there are a few important points:
Understand what specific problem a pattern solves, when to apply it and - even more - when not to apply it.
Patterns are often specific to some programming language/paradigm and don't necessary apply to other languages/paradigms as well.
Take the Visitor pattern:
It solves the problem of double dispatch in a language that only supports single dispatch. Giving it a name raises awareness and library writers that include visitors in their class hierarchy can greatly improve the extensibility of their classes.
OTOH should C++ ever get multi-methods, the visitor pattern will suddenly become obsolete in C++.
The observer pattern solves the problem of callbacks in an OO language that doesn't support directly callable objects (function pointers, closures etc). In a language where this is supported you don't need the observer pattern. But you use similar patterns. You still need half of the observer pattern, i.e. a "subject" that allows the registration of callbacks.
C# solves the same problem with events and delegates.
Every language has it's own, slightly varying patterns.
Of course, pattern are not the end of all problems and blindly combining the wrong pattern for the problem at hand will lead to an incomprehensible mess. But you can also achieve this without patterns.
Yeah, that’s why I think it’s more important to understand how those patterns are implemented, what they represent, and pick ideas from there and there.
I would welcome a collection of design patterns. Mainly to get inspiration on how to solve a problem. Why reinvent the wheel when there is a common practice... Coming from a purely OOP background I find it quite challenging sometimes to figure out a good way of doing things in RUST. An overview of design patterns would help, even if I wouldn't copy-paste the pattern but rather pick parts that I need for a current situation. A description of the problem with a pattern to solve it could be a time saver and a good learning experience.
I've been contemplating how using the