4 ms·
When I write Rust I tend to do so using functional/procedural patterns instead of object-oriented ones, and it doesn't seem like I run into issues like the ones
by im_down_w_otp 9y ago
When I write Rust I tend to do so using functional/procedural patterns instead of object-oriented ones, and it doesn't seem like I run into issues like the ones described here very often.
Much of this write-up seems to cover things that were/are complicated because of OOP's tight coupling of state and actions on that state & the intersection of that with the additional constraints and controls Rust places on state management.
I'm not entirely sure which style/patterns are more idiomatic. I just know which ones keep me out of trouble.
- bluejekyll 9y agoI don’t know about this. I think the trait system is so powerful of a concept for genetics and such that I find that I practice OO pretty regularly. I avoid dynamic polymorphism, but most OO practices translate really well into Rust.
- sixbrx 9y agoSounds closer to type classes usage a la Haskel than what I'd call OO (late binding)?
- bluejekyll 9y agoI try to capture data in a enum or struct, then define the operations available to that type. A trait allows me to capture common functionality across different types which implement that trait. With generics it allows me to be polymorphic. If that’s not OO, I don’t know what is :)
- Tarean 9y agoWell, technically traits dispatch based on type and not on value. As long as you aren't wrapping everything into trait objects that is much closer to functional programming. Seems like a mostly semantical difference, though. I guess there is a philosophical difference in whether you pass a large struct into a function or select the needed data at the call side and only pass that, though. Former might be easier to extend, latter is probably easier to test?