A trait object lets different concrete Rust types be used through one trait interface. Write `dyn Trait` where a concrete type would otherwise appear. Calls through that interface use dynamic dispatch: Rust looks up the implementation at run time through a compiler-generated vtable. This resembles virtual-method dispatch, but it does not make the types part of an inheritance hierarchy. section 2.2.6
Trait objects are unsized, so a `Vec<dyn MyTrait>` cannot hold them directly. Put each value behind a suitable smart pointer instead: `Vec<Box<dyn MyTrait>>`. `Box` permits an unsized target through its `?Sized` bound; ordinary generic type parameters require `Sized` by default. section 2.2.6
One vector, two implementations
Implement `MyTrait::trait_hello` for `MyStruct1` and `MyStruct2`, then push a boxed instance of each into `Vec<Box<dyn MyTrait>>`. Iterating over the vector can call `trait_hello()` on both values. It cannot call either struct’s separate `struct_hello()` method through the trait interface. section 2.2.6
Listing 10.11 Testing the polymorphism with trait objects
fn main() {
let dog = Box::new(Dog::new("Rusty"));
let cat = Box::new(Cat::new("Misty"));
let animals: Vec<Box<dyn Animal>> = vec![dog, cat];
for animal in animals {
println!("{} says {}", animal.name(), animal.speak());
}
}
See `Dog` and `Cat` stored as `Box<dyn Animal>` values and called through their shared `Animal` methods. section 10.6
If concrete-type behavior is needed, a trait can expose `&dyn Any` and callers can try `downcast_ref` for a particular type. Prefer the shared trait methods when they express the behavior you need. section 2.2.6
Use trait objects for this kind of mixed collection rather than implementing `Deref` to make one struct look like another. `Deref`-based imitation of a superclass is misleading; a trait states the shared interface directly. Dynamic dispatch is a tool, not a rule for every design. section 10.6 section 2.2.6
