Traits и generics в Rust без академического тумана

Traits и generics в Rust часто объясняют слишком академично. На практике их первая польза простая: trait описывает общее поведение, а generic-функция позволяет работать с разными типами, если они это поведение поддерживают

В этом уроке мы сделаем отчет. Разные типы смогут превращаться в строку отчета, а одна функция будет печатать любой отчет через trait bound

Что получится в конце

Создайте проект:

cargo new rust_traits
cd rust_traits

Код src/main.rs:

trait Report {
    fn render(&self) -> String;
}

struct TaskReport {
    title: String,
    done: bool,
}

struct ErrorReport {
    message: String,
}

impl Report for TaskReport {
    fn render(&self) -> String {
        format!("Task: {} / done: {}", self.title, self.done)
    }
}

impl Report for ErrorReport {
    fn render(&self) -> String {
        format!("Error: {}", self.message)
    }
}

fn print_report<T: Report>(item: &T) {
    println!("{}", item.render());
}

fn main() {
    let task = TaskReport {
        title: String::from("learn traits"),
        done: false,
    };

    let error = ErrorReport {
        message: String::from("network timeout"),
    };

    print_report(&task);
    print_report(&error);
}

Запуск:

cargo run

Trait: общий договор поведения

Trait:

trait Report {
    fn render(&self) -> String;
}

говорит: тип, который реализует Report, умеет отдать строку отчета через метод render

Trait не хранит поля. Он описывает поведение. Это похоже на интерфейс в других языках, но в Rust traits глубоко связаны с generics, ownership и системой типов

Когда мы пишем:

impl Report for TaskReport

мы обещаем компилятору: TaskReport умеет выполнять все, что требует Report

Generics: функция для разных типов

Функция:

fn print_report<T: Report>(item: &T) {
    println!("{}", item.render());
}

работает с любым типом T, если он реализует Report. Это и есть trait bound: ограничение на generic-тип

Без bound компилятор не знает, есть ли у T метод render. С bound он может проверить код во время компиляции и не пустить тип, который не умеет быть отчетом

Можно записать то же короче:

fn print_report(item: &impl Report) {
    println!("{}", item.render());
}

Для простых аргументов impl Trait читается легче. Для сложных связей между типами часто удобнее явный generic T

format! и String

В примере render возвращает String:

format!("Task: {} / done: {}", self.title, self.done)

format! похож на println!, но не печатает в терминал. Он собирает строку и возвращает ее

Это удобно для trait-метода: один код решает, как сформировать отчет, другой решает, куда его вывести

Так мы разделяем ответственность. TaskReport знает, как описать себя, а print_report знает, как напечатать любой отчет

Мини-практика: общий summary

Добавьте еще один тип:

struct UserReport {
    name: String,
    points: i32,
}

impl Report for UserReport {
    fn render(&self) -> String {
        format!("User: {} / points: {}", self.name, self.points)
    }
}

И вызов:

let user = UserReport {
    name: String::from("Dinar"),
    points: 95,
};

print_report(&user);

Функцию print_report менять не нужно. Это хороший признак правильной абстракции: новый тип добавился, общий код продолжил работать

Trait bound с несколькими требованиями

Иногда тип должен поддерживать несколько traits:

fn debug_report<T: Report + std::fmt::Debug>(item: &T) {
    println!("{item:?}");
    println!("{}", item.render());
}

Здесь T должен реализовать и Report, и Debug. Для своего типа можно добавить:

#[derive(Debug)]
struct TaskReport {
    title: String,
    done: bool,
}

Не надо начинать с таких конструкций в первом примере. Но полезно видеть, что constraints можно наращивать постепенно

Когда generics не нужны

Если функция работает только с одним конкретным типом, generic не нужен:

fn print_task(task: &TaskReport) {
    println!("{}", task.render());
}

Generics полезны, когда у вас действительно есть несколько типов с общим поведением. Иначе они только делают код тяжелее для чтения

Хороший вопрос перед trait: «У меня уже есть два типа, которые должны вести себя одинаково?» Если да, trait может быть уместен. Если нет, начните с обычной функции или метода

Where-синтаксис для длинных bounds

Когда ограничений становится много, сигнатура может разрастись:

fn print_debug_report<T: Report + std::fmt::Debug>(item: &T) {
    println!("{item:?}");
    println!("{}", item.render());
}

Можно написать через where:

fn print_debug_report<T>(item: &T)
where
    T: Report + std::fmt::Debug,
{
    println!("{item:?}");
    println!("{}", item.render());
}

Это та же логика, но длинные ограничения читаются спокойнее. Для первого примера T: Report достаточно, но where стоит узнавать рано: он часто встречается в реальных библиотеках

Trait с реализацией по умолчанию

Trait может дать метод по умолчанию:

trait Report {
    fn render(&self) -> String;

    fn print(&self) {
        println!("{}", self.render());
    }
}

Теперь каждый тип обязан реализовать render, но print получает бесплатно. Если конкретному типу нужно другое поведение, он может переопределить метод

Это полезно, когда у всех типов есть общий способ действия, построенный поверх одного обязательного метода. Так trait становится не только договором, но и местом для общей логики

Возвращать impl Trait

impl Trait можно использовать в возвращаемом значении:

fn build_report() -> impl Report {
    TaskReport {
        title: String::from("generated"),
        done: true,
    }
}

Функция скрывает конкретный тип и обещает только то, что результат реализует Report. Это удобно для API, где вызывающему коду не важно, какой именно тип внутри

Но есть ограничение: такая функция должна возвращать один конкретный тип во всех ветках. Если в одной ветке TaskReport, а в другой ErrorReport, простой impl Report уже не подойдет без дополнительных приемов

Почему trait object пока рано

Вы можете встретить Box<dyn Report>. Это trait object: способ хранить разные типы за общей динамической оболочкой. Тема полезная, но для первого урока по traits она перегружает картину

Сначала достаточно статических generics: fn print_report<T: Report>(item: &T). Они проще для компилятора, проще для новичка и хорошо показывают главный смысл traits

Частые ошибки и порядок проверки

Создали trait, но не реализовали метод Если trait требует render, каждый impl Report for Type должен дать реализацию render

Пишете generic без bound Компилятор не знает, какие методы доступны у T. Добавьте T: Report, если вызываете render

Делаете trait слишком рано Если общий интерфейс нужен только одному типу, скорее всего, пока достаточно метода в impl

Путаете trait и struct Struct хранит данные. Trait описывает поведение. impl связывает одно с другим

Мини-практика: Vec с отчетами одного типа

Сначала не пытайтесь хранить разные типы отчетов в одном Vec. Начните с одного типа:

let reports = vec![
    TaskReport {
        title: String::from("write"),
        done: true,
    },
    TaskReport {
        title: String::from("publish"),
        done: false,
    },
];

for report in &reports {
    print_report(report);
}

Это закрепляет главный сценарий generics: функция общая, а коллекция пока конкретная. Такой код проще читать и проще компилировать

Когда действительно потребуется хранить разные реализации Report в одном списке, можно изучать trait objects. Но если прыгнуть туда слишком рано, тема traits превратится в туман из dyn, Box и времени жизни

Traits как граница модуля

Trait часто полезен как граница между частями программы. Например, одна часть умеет собирать данные, другая — печатать отчет, а между ними договор Report

Такой договор снижает связность. Функции не обязаны знать все поля TaskReport или ErrorReport. Им достаточно знать: объект умеет render. Это и есть практическая польза trait, а не абстракция ради красивых слов

Что может быть еще интересно по этой теме

Traits заменяют наследование? Они решают часть задач, для которых в других языках используют интерфейсы или наследование. Но Rust обычно строит композицию поведения, а не иерархии классов

Generics делают код медленнее? Обычно нет в привычном смысле. Rust часто мономорфизирует generic-код, создавая конкретные версии под типы во время компиляции

Когда использовать impl Trait? Для простых аргументов и возвращаемых значений он делает сигнатуру легче. Когда нужно связать несколько аргументов одним типом, явный T понятнее

Что дальше после traits? CLI-проект. Там traits не будут главной темой, зато пригодятся Result, строки, коллекции и аккуратная структура кода

Что почитать дальше по Rust

• Struct, enum и impl в Rust
• CLI на Rust: мини-проект с аргументами командной строки
• Типы, match, Option и Result в Rust
• Rust и C++: что выбрать для системного кода