Существуют ли какие-либо модели проектирования ржавчины, например, функции безопасности объектов?

Я новичок в Rust. Мне бы очень хотелось однажды иметь возможность писать безопасный код с помощью Rust. Я вижу все причины его существования и его цели, и я согласен с ним на 100%. Изучив довольно много разных языков, я сказал себе, что не буду изучать новые языки. Я думаю, что Rust заслуживает исключения.

В любом случае.

Есть вещи, с которыми у меня большие проблемы. Например:

pub trait PrivateKey {
   fn generate(&self) -> Self;
}

pub struct Node {
   pk: Box,
}

Это не компилируется из-за безопасности объектов. Я понимаю, почему это необходимо. Но потом я изо всех сил пытаюсь решить эти проблемы.

1. Вероятно, вполне законно хотеть другого типа PrivateKey реализации, потому что разные уже существуют, и могут появиться новые.
2. Я хочу, чтобы мой узел имел ссылку на закрытый ключ, потому что он должен использоваться во многих случаях.

Поэтому я хочу определить в одном месте какова реализация PrivateKey и затем можно будет ее использовать. Я хочу создать его экземпляр (так что нет new функция в типаже), но затем иметь возможность генерировать фактические байты и возвращать свой экземпляр. Таким образом, я мог бы использовать один и тот же абстрактный код в одном месте для создания нового закрытого ключа, а затем использовать его.

Но безопасный признак для объектов не может вернуться. Self. Итак, как я могу проектировать с учетом таких проблем? Есть ли общие закономерности или (как мне на самом деле кажется) каждый раз искать нестандартные решения?

Если вы можете жить, упаковывая и всегда очищая PrivateKey, у вас может быть признак fn, который возвращает упакованный/очищенный тип:

        pub trait PrivateKey {
            fn generate(&self) -> Box;
        }

(Я предполагаю, что вы имеете в виду pub struct Node кстати, там ни тире.)

О да, извините, это явно структура. Я отредактирую сообщение.

Что вы подразумеваете под словом стирать?

Это то, что dyn SomeTrait вызывается, поскольку тип, реализующий эту особенность, потерян/стерт.

Работает ли у вас черта fn, которую я описал?

Подпись та же самая Clone::clone. Может быть, ты ищешь способ клонирования Box.

Заставить struct ImplementorOfTrait имеет dyn Trait (как в Box также называется «стиранием типа».

Если вместо клонирования Box вы хотели получить базовый тип, он есть принижение вошел бы. Или, может быть, вам стоит переосмыслить идею использования типажей-объектов, если это так — в Rust реже печатают delete и пытаются повсюду выполнять понижающие приведения. Может быть, вы хотите ДЕЛАТЬ Node универсальный с PrivateKey + Clone вместо этого связаны там, где это необходимо. Или, может быть, использовать enum вместо этого, если вам нужно всего несколько локальных реализаций.

Да, это работает для меня. Я не могу оценить, лучший ли это способ сделать это для моего варианта использования, но на данный момент это работает! Думаю, я могу пометить это как решение.

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

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

Итак, мой другой вопрос: существуют ли какие-либо шаблоны проектирования или образовательные ресурсы, которые обучают этому? Или вы учитесь по ходу дела, применяя решения к текущей проблеме и, таким образом, учитесь шаг за шагом? Не знаю, имеет ли смысл мой вопрос…

Возможно, вам захочется подумать о том, что сказал @quinedot о подписании контракта. generate. Странно, что у него есть &self параметр, поскольку это означает, что он создает PrivateKey из другого PrivateKey. Поэтому мы задаемся вопросом, действительно ли вам нужен этот метод в вашей сфере, и может ли возникнуть недоразумение. Вы пытаетесь создать признак для фабрики закрытых ключей?

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

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

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

Но я думаю, что вы на правильном пути, когда говорите, что сначала вам нужно понять, как их генерировать.