Состояние реализации трейтов в Rust

Но никакой государственности!

просто неправильно, хотя вы не можете реализовать эту конкретную черту для любого типа, и crate1::Water просто не является одним из типов, для которых вы можете ее реализовать.

Вы наверняка могли бы реализовать это с помощью этой альтернативы Water:

pub struct Water {
    pub temperature: i32,
    pub state: String,
}

Поэтому исходное утверждение следует перефразировать так:
Не существует состояния, которое не предоставляет внешний тип.

Альтернативно, вы всегда можете добавить произвольное состояние, реализовав Matter для пользовательского типа оболочки вместо внешнего типа напрямую:

struct MatterialWater {
    water: crate1::Water,
    temperature: i32,
    state: String,
}

Наследование состояний и признаков с вариантом шаблона декоратора

В этом ответе рассматривается более общий вопрос о том, как состояние и характеристики могут быть связаны в иерархических отношениях.

Что касается вопроса ОП, шаблон декоратора можно применять к объектам из внешних ящиков, которые имеют функции, которые можно считать полезными, но которые необходимо расширить. Можно создать свою собственную структуру Water, в которой есть поле, содержащее поля другого ящика Water, и использовать ее методы в своей собственной impl.

Остальная часть этого подхода не касается конкретно применения шаблона декоратора к предметам из других ящиков. В более общем плане речь идет о том, как применять шаблон декоратора и использовать возможности языка для достижения иерархии объектов.

Вы можете добиться сохранения состояния в иерархии типов объектов посредством комбинации свойств и структур. Это действительно требует немало накладных расходов; разделение большого проекта на файлы для каждого типа может помочь в управлении им.

Ниже в общих чертах применяется основная идея Шаблона декоратора для достижения целей объектно-ориентированного проектирования, когда «подклассы» наследуют поведение, а также косвенно определяют его.

Идея состоит в том, чтобы иметь структуру, тесно связанную с признаком. Признак определяет нереализованный метод, который возвращает ссылку на связанную с ним структуру состояния, которая реализована «подклассами».

В признаке поведение или методы могут иметь реализации, которые будут автоматически наследоваться «подклассами».

ссылка на игровую площадку ржавчины

// ---  canine.rs ---

pub struct CanineState {
    is_sleeping: bool,
}
impl CanineState {
    pub fn new() -> Self {
        Self { is_sleeping: false }
    }
}

pub trait Canine {
    fn canine_mut(&mut self) -> &mut CanineState;

    // Predefined behavior all subclasses can use.    
    fn sleep(&mut self, b: bool) {
        println!("CanineState.is_sleeping = {b}");
        self.canine_mut().is_sleeping = b;
    }
}

// --- dog.rs ---

pub struct DogState {
    // Canine characteristics.
    canine_state: CanineState,
    
    // New dog characteristics.
    is_barking: bool,
}
impl DogState {
    pub fn new() -> Self {
        Self { canine_state: CanineState::new(), is_barking: false }
    }
    // Give subclasses a way to get the superclass' state.
    fn canine_mut(&mut self) -> &mut CanineState {
        &mut self.canine_state
    }
}

// Note the semantics here `Dog: Canine`. This declares that a Dog
// is a Canine.
pub trait Dog: Canine {
    // Unimplemented in virtual method.
    fn dog_mut(&mut self) -> &mut DogState;
    
    // Virtual behavior with implementation.
    fn bark(&mut self, b: bool) {
        println!("DogState.is_barking = {b}");
        self.dog_mut().is_barking = b;
    }
}

// --- pug.rs ---

// A Pug is a Dog which is a Canine.
//
pub struct Pug {
    dog_state: DogState,
    is_snorting: bool,
}
impl Pug {
    pub fn new() -> Self {
        Self { dog_state: DogState::new(), is_snorting: false }
    }
    // Pug has no subclasses, so we can implement its behaviors as 
    // struct funcs.
    pub fn snort(&mut self, b: bool) {
        println!("Pug.is_snorting = {b}");
        self.is_snorting = b
    }
}

// Implement the state accessor and automatically get all predefined 
// Dog behaviors.
//
impl Dog for Pug {
    // Only need to implement this.
    fn dog_mut(&mut self) -> &mut DogState {
        &mut self.dog_state
    }
}

// Implement the state accessor and automatically get all predefined 
// Canine behaviors.
//
impl Canine for Pug {
    // Only need to implement this. 
    fn canine_mut(&mut self) -> &mut CanineState {
        self.dog_state.canine_mut()
    }
}

fn main() {
    let mut pug = Pug::new();
    pug.snort(true);
    pug.bark(true);
    pug.bark(false);
    pug.snort(false);
    
    pug.sleep(true);
}

Pug.is_snorting = true
DogState.is_barking = true
DogState.is_barking = false
Pug.is_snorting = false
CanineState.is_sleeping = true

Современная тенденция в ООП заключается в отказе от глубоких и/или сложных иерархий. В прошлом многие объектно-ориентированные проекты страдали от архитектурных недостатков, таких как хрупкий базовый класс. Отношения «использование» являются предпочтительными, если нет веской причины для реализации иерархии. Шаблон «Декоратор» — это тип отношений использования, но он также может стать громоздким, если им злоупотреблять. Хорошая идея — сохранять иерархические отношения поверхностными и простыми.

Каждому, кто утверждает, что Rust не является объектно-ориентированным, я бы возразил, что стандартные библиотеки и популярные пакеты Rust на самом деле являются объектно-ориентированными. Хотя наследование состояний не поддерживается языком напрямую через структуры, вы видите множество примеров наследования поведения через признаки. Сам факт реализации пользовательского итератора с использованием типажа Iterator дает разработчику множество новых вариантов поведения, унаследованных от интерфейса. В язык встроено множество других объектно-ориентированных функций, помимо простого наследования поведения (полиморфизм/динамическая диспетчеризация).

Является ли Rust «ОО-языком» или нет, может зависеть от того, как человек лично определяет, что такое ОО-язык. Rust не поддерживает напрямую наследование состояний, но в остальном поддерживает основные функции объектно-ориентированного языка. Шаблоны проектирования GoF и другие объектно-ориентированные стратегии можно легко реализовать с помощью Rust.

Если вы новичок в Rust, не отказывайтесь от всех своих стремлений применить знакомые концепции объектно-ориентированного подхода к своим собственным проектам или вообще отказывайтесь от Rust только потому, что кто-то на раннем этапе сказал вам: «Rust — это не объектно-ориентированный подход». . С учетом вышесказанного, Rust — это уникальный и несколько сложный язык, в котором нельзя слепо пытаться привести его в соответствие со своими представлениями о том, как можно применять объектно-ориентированный подход. Существует множество идиоматических способов реализации функций Rust, с которыми следует ознакомиться, прежде чем принимать решения по проектированию.