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!
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).
Thanks for your input! I’ll have a look at both build flags and macros for sure! For my specific problem enums will do just fine I guess, but having an overview about the possibilities helps a lot!