I find these videos give a very visual explanation and help to put you into the right mindset: http://intorust.com/
(You can skip the first two videos.)
Sort of when it clicked for me, was when I realized that your code needs to be a tree of function calls.
I mean, that’s what all code is anyways, with a main-function at the top calling other functions which call other functions. But OOP adds a layer to that, i.e. objects, and encourages to do all function calls between objects. You don’t want to do that in Rust. You kind of have to write simpler code for it to fall into place.
To make it a bit more concrete:
You will have functions which hold ownership over some data, typically because they instantiated a struct. These sit at the root of a sub-tree, where you pass access to this data down into further functions by borrowing it to them.
You don’t typically want to pass ownership all over the place, nor do you typically want to borrow (or pass references) to functions which are not part of this sub-tree.
Of course, there’s situations where this isn’t easily possible, e.g. when having two independent threads talking to each other, and then you do need Rc or Arc, but yeah, the vast majority of programming problems can be solved with trees of function calls.
Sort of when it clicked for me, was when I realized that your code needs to be a tree of function calls.
I mean, that’s what all code is anyways, with a main-function at the top calling other functions which call other functions. But OOP adds a layer to that, i.e. objects, and encourages to do all function calls between objects. You don’t want to do that in Rust. You kind of have to write simpler code for it to fall into place.
Yes, this ties in with what I’m saying though. You need a paradigm shift in your design philosophy, which is hard when you come from a Cx background.
I also think that in OO there shouldn’t be much cross contamination. It happens (and it happens a lot in my personal projects to be fair) but when well designed it shouldn’t need to be. In C# for example it should be the case that rather than a function owning a resource, a class should. So when using an object between classes you take it as a reference from a method in one class and pass it into a method to another class rather than call that class and make it a dependency of that class too. In this way you would have a one way dependency, rather than a two way.
This kind of thinking has moved into creating objects in rust. Also I think yes within a same class the idea of a function (that isn’t static) accepting an object that is part of the class that was returned by another function in the case class feels very wrong from a Cx style point of view. If we knew we were going to do that, we’d just make it a class level variable and use it in both functions.
Like I say, just another way of thinking and I’m not there yet.
I find these videos give a very visual explanation and help to put you into the right mindset: http://intorust.com/
(You can skip the first two videos.)
Sort of when it clicked for me, was when I realized that your code needs to be a tree of function calls.
I mean, that’s what all code is anyways, with a main-function at the top calling other functions which call other functions. But OOP adds a layer to that, i.e. objects, and encourages to do all function calls between objects. You don’t want to do that in Rust. You kind of have to write simpler code for it to fall into place.
To make it a bit more concrete:
You will have functions which hold ownership over some data, typically because they instantiated a struct. These sit at the root of a sub-tree, where you pass access to this data down into further functions by borrowing it to them.
You don’t typically want to pass ownership all over the place, nor do you typically want to borrow (or pass references) to functions which are not part of this sub-tree.
Of course, there’s situations where this isn’t easily possible, e.g. when having two independent threads talking to each other, and then you do need
RcorArc, but yeah, the vast majority of programming problems can be solved with trees of function calls.Yes, this ties in with what I’m saying though. You need a paradigm shift in your design philosophy, which is hard when you come from a Cx background.
I also think that in OO there shouldn’t be much cross contamination. It happens (and it happens a lot in my personal projects to be fair) but when well designed it shouldn’t need to be. In C# for example it should be the case that rather than a function owning a resource, a class should. So when using an object between classes you take it as a reference from a method in one class and pass it into a method to another class rather than call that class and make it a dependency of that class too. In this way you would have a one way dependency, rather than a two way.
This kind of thinking has moved into creating objects in rust. Also I think yes within a same class the idea of a function (that isn’t static) accepting an object that is part of the class that was returned by another function in the case class feels very wrong from a Cx style point of view. If we knew we were going to do that, we’d just make it a class level variable and use it in both functions.
Like I say, just another way of thinking and I’m not there yet.