Ответ.

В Rust нет традиционных конструкторов как в C++ или Java, но для создания объектов типов обычно используют ассоциированные функции (часто с именем new) и так называемые фабричные методы. Это связано с историей языка, где особое внимание уделяется безопасности и явности инициализации: только явно написанная и вызываемая функция отвечает за корректную инициализацию каждого поля структуры.

История вопроса

Изначально в Rust инициализация структур допускала прямое назначение всех полей (так называемый "struct literal" синтаксис). Однако, чтобы обеспечить инвариантность, скрыть детали и реализовать дополнительные проверки, практикуется использование фабричных методов (impl SomeStruct { fn new(...) -> Self { ... } }) или даже генерализация через шаблоны (builder pattern).

Проблема

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

Решение

В Rust рекомендуется создавать фабричные методы, которые возвращают полностью инициализированный объект, при необходимости выполняют валидацию и скрывают детали инстанциирования.

Пример кода:

struct User {
    username: String,
    age: u8,
}

impl User {
    pub fn new(username: String, age: u8) -> Option<Self> {
        if age >= 18 {
            Some(Self { username, age })
        } else {
            None
        }
    }
}

fn main() {
    let user = User::new("Alice".to_string(), 20);
    // user: Option<User>, безопасно обработать ошибку
}

Ключевые особенности:

Нет автоматических конструкторов как в ряде других языков, но есть имплементация через ассоциированные функции (fn new).
Фабричные методы позволяют реализовывать проверки целостности и скрыть детали внутренней реализации.
Эффективно поддерживается паттерн builder, когда необходимо множество опциональных параметров и поэтапная инициализация.

Вопросы с подвохом.

Можно ли сделать приватные поля в структуре, чтобы нельзя было создавать экземпляры напрямую вне модуля?

Да, если сделать все поля структуры приватными и предоставить только публичные фабричные методы, структура не может быть инициализирована вне своего модуля напрямую.

Всегда ли фабричный метод должен называться new?

Нет, это соглашение, но не обязательство. Для разных стратегий инициализации пользуются именами вроде "with_capacity", "from_config", "from_env" и так далее.

Могут ли быть приватные конструкторы?

Да, если ассоциированная функция объявлена как fn new(...) -> Self без модификатора pub, её нельзя будет вызвать вне этого модуля. Это позволяет, например, реализовывать singleton, enforce factory или скрытую инициализацию.

Типовые ошибки и анти-паттерны

Создание структуры с публичными полями, позволяющее обойти инварианты или получить объект в невалидном состоянии.
Не использовать фабричные методы для сложных структур с внешними ресурсами.
Путаница между конструктором и методом-валидатором: например, возвращать Result/Option, хотя отказ в инициализации означает логику другого уровня.

Пример из жизни

Негативный кейс

Прямое использование структуры с открытыми полями, без фабричного метода:

struct Connection {
    fd: i32,
    timeout: u64,
}

let c = Connection { fd: -1, timeout: 10 }; // fd: -1 невалидно для дескриптора!

Плюсы:

Скорость прототипирования.
Меньше кода.

Минусы:

Нет гарантии, что объект не будет в невалидном состоянии.
Ошибки появляются только во время исполнения.

Позитивный кейс

Использование приватных полей и фабричного метода:

pub struct Connection {
    fd: i32,
    timeout: u64,
}

impl Connection {
    pub fn new(fd: i32, timeout: u64) -> Option<Self> {
        if fd >= 0 {
            Some(Self { fd, timeout })
        } else {
            None
        }
    }
}

Плюсы:

Компилятор не даст создать невалидный объект.
Явное управление проверками.

Минусы:

Немного увеличивается объем кода.
Не для всех простых структур требуется такой паттерн.