Hey there, I’m currently learning Rust (coming from object-oriented and also to some degree functional languages like Kotlin) and have some trouble how to design my software in a Rust-like way. I’m hoping someone could help me out with an explanation here :-)
I just started reading the book in order to get an overview of the language as well.
In OOP languages, I frequently use design patterns such as the Strategy pattern to model interchangeable pieces of logic.
How do I model this in Rust?
My current approach would be to define a trait and write different implementations of it. I would then pass around a boxed trait object (Box<dyn MyTrait>). I often find myself trying to combine this with some poor man’s manual dependency injection.
This approach feels very object oriented and not native to the language. Would this be the recommended way of doing things or is there a better approach to take in Rust?
Thanks in advance!
Minor nit: Kotlin is decidedly not a functional language.
Design patterns in OOP exist purely to solve the problems created by OOP itself. If you have a language with proper ADTs and higher order functions, the need for traditional design patterns disappear since the problems they solve are first-class features baked into the language.
The first-class replacement for the Strategy pattern (and many other patterns such as the Visitor pattern) is sum types (called enums in Rust).
Truth has been spoken.
Except that Kotlin is functional (just like Rust, C++, Visual Basic, JavaScript,…). It is, however, not Pure Functional (like Haskell or Lean4 would be - if you haven’t checked out Lean4, I can recommend it, great fun).
(Sauce: https://en.wikipedia.org/wiki/List_of_programming_languages_by_type#Functional_languages)
That list also counts Java and C# as “functional languages”. I wouldn’t take it too seriously. Ocaml, Scala, F#, etc. are impure functional languages. Kotlin absolutely is not. Having a couple of features you might find in functional languages does not make a language functional. Kotlin is still very much an OOP-based language. It’s basically a somewhat nicer Java.
I know, from a mathematics standpoint it does not make sense, but from how the term is used nowadays in programming it does: Those languages allow to compose functions, pass functions as parameters, return functions, etc.
Traits like std::io::Write are essentially Strategy pattern. Take a look at how that’s used. You’re doing it mostly how I would, except for the Box<dyn T>. Generally it’s preferred to use generic functions/types in Rust instead of dynamic dispatch, i.e. have a fn do_something<T: MyTrait>(imp: T) instead of a fn do_something(imp: &dyn MyTrait).
For a direct replacement, you might want to consider enums, for something like
enum Strategy {
Foo,
Bar,
}
That’s going to be a lot more ergonomic than shuffling trait objects around, you can do stuff like:
fn execute(strategy: Strategy) {
match strategy {
Strategy::Foo => { ... }
Strategy::Bar => { ... }
}
If you have known set of strategy that isn’t extensible, enums are good. If you want the ability for third party code to add new strategies, the boxed trait object approach works. Consider also the simplest approach of just having functions like this:
fn execute_foo() { ... }
fn execute_bar() { ... }
Sometimes, Rust encourages not trying to be too clever, like having get vs get_mut and not trying to abstract over the mutability.
Thanks for the explanation! I think just using an enum will do perfectly well in my case.
To expand on why generics are preferred, just in case you haven’t seen these points yet: the performance downsides of Box<dyn MyTrait> are,
- methods use dynamic dispatch in this case
- requires heap allocation
There is also a possible type theory objection which is that normally there is a distinction between types and traits. Traits are not types themselves, but instead define sets of types with shared behavior. (That’s why the same feature in Haskell is called a “type class”, because it defines a class of types that have something in common.) But dyn turns a trait into a type which undermines the type/trait distinction. It’s useful enough to justify being in the language, but a little unsettling from a certain perspective.
That makes sense, thanks again! I think dynamic dispatch is not as much of a performance issue in my case, yet you’re totally right not to waste resources that aren’t actually needed. Keeping things on the stack if possible is also a good thing.
I’ll definitely need to read more about Rusts type system but your explanation was already very helpful! I think this might be why my initial approach felt unnatural - it works but is quite cumbersome and with generics there seems to be a more elegant approach.
There’s nothing wrong with using dyn if the problem calls for it. In most cases it’s more idiomatic to use an enum to represent something like a strategy, but if your strategies are complicated entities in themselves, a trait is probably the right approach.
I agree with the other suggestions so far, to wit:
1.dyn is fine, when you need it. People will give you a lot of guff about performance but vtable lookup on a dyn is no less performant than the same thing in C++ (in higher level languages almost every call is dynamically dispatched and those are used for plenty of serious, performant work).
-
Use enums more.
-
Use traits and generic functions
And I would add a couple of other thoughts.
For some DI type work, you can use cargo’s Features to define custom build flags. You can then put variants on the same code (usually implementing a trait) in different modules and use conditional compilation on the Features to swap out which code is used. This is like a compile-time strategy pattern. I use it for testing, but also to swap out databases (using a local in-memory to test and a real one in prod) and to swap out graphical backends on my roguelike (compiles to OpenGL on windows but Metal on my Mac).
You’ll probably want to learn Rust’s macro system sooner than later as well. Sometimes a macro is better than a function when you need to generically operate over several types (function argument overloading, in other languages) or work on something in a general but well-structured way (tree walking for example).
