Your customer, product and order are still going to be objects, but they won’t reference each other directly with references/pointers. Instead they’ll either store an id, or you’ll have a central registry of relationships using some kind of id (could be a key into a hashmap or an index into a vector) and then fetch data from the central store (or have the caller pass it in) at the last minute when running code that does something.

> they won’t reference each other directly with references/pointers

I'm not sure if I understood your reply correctly, but there seems to be nothing in Rust stopping one dynamic trait (interface-based) object directly referencing another dynamic trait (interface-based) object. The main difference between C++ O-O and Rust trait-oriented programming is C++ inheritance of implementation vs. Rust inheritance of interfaces. You can also downcast in Rust, if you try hard enough.

https://gist.github.com/rust-play/fbe471b12a0fabe4ab7b653835...

You can do references in Rust. But you can only have one mutable reference to an object at once unless you work around this with locks (Mutex, RefCell, etc). So for anything other than trivial child object references, you can quickly paint yourself into a corner of compilation errors by using webs of references. And this seems to be the basis of a lot of people's frustrations with Rust.

It's true that you also can't do inheritance. But I've found this tends to be less of a problem as most OOP languages encourage composition over inheritance anyway, and composition works the same in Rust as in other languages.

I definitely see your point about the interconnection of references, mutability and lifetime in Rust, but I guess the issue of whether Rust has a problem with the classic O-O comes down to the question of what you are trying to implement. If you are implementing a graph-like data structure (for example, UI widgets in a window), you need to keep track of multiple mutable constituent structures; in that situation, Rust references indeed are problematic for the classic O-O and you need Rc<>/RefCell<> smart pointer shenanigans. If you are implementing an actor (an algorithm, a subsystem, a process, etc. - for example, a Product, a Customer and an Order), you usually need to keep track of only a handful of structures representing the input to an actor, all of them likely immutable (a mutable actor with its input kept immutable to eliminate unexpected input side-effects); in that situation, Rust has no problem with the classic O-O, since abstractions can be expressed through references to trait objects.

The nice thing about doing it this way is that it makes it much easier to serialize and/or save to a database.

The major gist with Rust is that you only build `structs` with the basic data, and very important, stick things together with `traits` and/or `enums`.

So, for my eCommerce app I have something like

  struct Line {
    order_id: usize,
    product_name: String
  }

  
  struct Order {
    order_id: usize,
    customer: Customer,
    lines: Vec<Lines>
  }

And this means instead of pointers, using ids (alike RDBMS) is much nicer overall (work wonders that the data is already like that in RDBMS!).

You can avoid ids and just embed the data too.

Following the idea of think like in databases, when you need to find fast bring a HashMap/BtreeMap:

  struct Line {
    order_id: usize,
    product_name: String
  }

  
  struct Order {
    order_id: usize,
    customer: Customer,
    lines: BtreeMap<usize, Lines> <-- BTree nice for ordered data and range queries!
  }