Файл: Язык программирования Rust.pdf

Скачать файл (7,02Мб)

Заказать решение

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 11.01.2024

Просмотров: 1158

Скачиваний: 5

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

СОДЕРЖАНИЕ

Недействительные ссылкиВ языках с указателями легко ошибочно создать висячий указатель — указатель,ссылающийся на место в памяти, которое могло быть передано кому-то другому после освобождения этой части памяти, сохраняя при этом указатель на неё. В Rust, напротив,компилятор гарантирует, что ссылки никогда не будут висячими: если у вас есть ссылка на какие-то данные, компилятор убедится, что данные не выйдут за пределы области видимости до того, как это сделает ссылка на них.Давайте попробуем создать висячую ссылку, чтобы увидеть, как Rust предотвращает их появление с помощью ошибки во время компиляции:Файл: src/main.rsЗдесь ошибка:Это сообщение об ошибке относится к особенности языка, которую мы ещё не рассмотрели: времени жизни. Мы подробно обсудим времена жизни в главе 10. Но если вы не обращаете внимания на части, касающиеся времени жизни, сообщение будет содержать ключ к тому, почему этот код является проблемой:fn main() { let reference_to_nothing = dangle(); } fn dangle() -> &String { let s = String::from("hello"); &s } $ cargo run Compiling ownership v0.1.0 (file:///projects/ownership) error[E0106]: missing lifetime specifier --> src/main.rs:5:16 | 5 | fn dangle() -> &String { | ^ expected named lifetime parameter | = help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from help: consider using the `'static` lifetime | 5 | fn dangle() -> &'static String { |

Определение и инициализация структурСтруктуры похожи на кортежи, рассмотренные в разделе "Кортежи", так как оба хранят несколько связанных значений. Как и кортежи, части структур могут быть разных типов.В отличие от кортежей, в структуре необходимо именовать каждую часть данных для понимания смысла значений. Добавление этих имён обеспечивает большую гибкость структур по сравнению с кортежами: не нужно полагаться на порядок данных для указания значений экземпляра или доступа к ним.Для определения структуры указывается ключевое слово struct и её название.Название должно описывать значение частей данных, сгруппированных вместе. Далее, в фигурных скобках для каждой новой части данных поочерёдно определяются имя части данных и её тип. Каждая пара имя: тип называется полем. Листинг 5-1 описывает структуру для хранения информации об учётной записи пользователя:Листинг 5-1: Определение структуры UserПосле определения структуры можно создавать её экземпляр, назначая определённое значение каждому полю с соответствующим типом данных. Чтобы создать экземпляр, мы указываем имя структуры, затем добавляем фигурные скобки и включаем в них пары ключ: значение (key: value), где ключами являются имена полей, а значениями являются данные, которые мы хотим сохранить в полях. Нет необходимости чётко следовать порядку объявления полей в описании структуры (но всё-таки желательно для удобства чтения). Другими словами, объявление структуры - это как шаблон нашего типа, в то время как экземпляр структуры использует этот шаблон, заполняя его определёнными данными, для создания значений нашего типа. Например, можно объявить пользователя как в листинге 5-2:Листинг 5-2: Создание экземпляра структуры UserЧтобы получить конкретное значение из структуры, мы используем запись через точку.Например, чтобы получить доступ к адресу электронной почты этого пользователя, мы structUser { active: bool, username: String, email: String, sign_in_count: u64, } fn main() { let user1 = User { email: String::from("someone@example.com"), username: String::from("someusername123"), active: true, sign_in_count: 1, }; } используем user1.email. Если экземпляр является изменяемым, мы можем поменять значение, используя точечную нотацию и присвоение к конкретному полю. В Листинге5-3 показано, как изменить значение в поле email изменяемого экземпляра UserЛистинг 5-3: Изменение значения в поле email экземпляра UserЗаметим, что весь экземпляр структуры должен быть изменяемым; Rust не позволяет помечать изменяемыми отдельные поля. Как и для любого другого выражения, мы можем использовать выражение создания структуры в качестве последнего выражения тела функции для неявного возврата нового экземпляра.На листинге 5-4 функция build_user возвращает экземпляр User с указанным адресом и именем. Поле active получает значение true, а поле sign_in_count получает значение1Листинг 5-4: Функция build_user, которая принимает email и имя пользователя и возвращает экземпляр UserИмеет смысл называть параметры функции теми же именами, что и поля структуры, но необходимость повторять email и username для названий полей и переменных несколько утомительна. Если структура имеет много полей, повторение каждого имени станет ещё более раздражающим. К счастью, есть удобное сокращение!Использование сокращённой инициализации поляТак как имена входных параметров функции и полей структуры являются полностью идентичными в листинге 5-4, возможно использовать синтаксис сокращённойfn main() { let mut user1 = User { email: String::from("someone@example.com"), username: String::from("someusername123"), active: true, sign_in_count: 1, }; user1.email = String::from("anotheremail@example.com"); } fn build_user(email: String, username: String) -> User { User { email: email, username: username, active: true, sign_in_count: 1, } } инициализации поля, чтобы переписать build_user так, чтобы он работал точно также,но не содержал повторений для email и username, как в листинге 5-5.Листинг 5-5: Функция build_user, использующая сокращённую инициализацию поля, когда параметры email и username имеют те же имена, что и поля structЗдесь происходит создание нового экземпляра структуры User, которая имеет поле с именем email. Мы хотим установить поле структуры email значением входного параметра email функции build_user. Так как поле email и входной параметр функции email имеют одинаковое название, можно писать просто email вместо кода email: emailСоздание экземпляра структуры из экземпляра другой структуры спомощью синтаксиса обновления структурыЧасто бывает полезно создать новый экземпляр структуры, который включает большинство значений из другого экземпляра, но некоторые из них изменяет. Это можно сделать с помощью синтаксиса обновления структуры.Сначала в листинге 5-6 показано, как обычно создаётся новый экземпляр User в user2без синтаксиса обновления. Мы задаём новое значение для email, но в остальном используем те же значения из user1, которые были заданы в листинге 5-2.Листинг 5-6: Создание нового экземпляра User с использованием некоторых значений из экземпляра user1Используя синтаксис обновления структуры, можно получить тот же эффект, используя меньше кода как показано в листинге 5-7. Синтаксис указывает, что оставшиеся поля fn build_user(email: String, username: String) -> User { User { email, username, active: true, sign_in_count: 1, } } fn main() { // --snip-- let user2 = User { active: user1.active, username: user1.username, email: String::from("another@example.com"), sign_in_count: user1.sign_in_count, }; } устанавливаются неявно и должны иметь значения из указанного экземпляра.Листинг 5-7: Использование синтаксиса обновления структуры для установки нового значения email дляэкземпляра User, но использование остальных значений из экземпляра user1Код в листинге 5-7 также создаёт экземпляр в user2, который имеет другое значение для email, но с тем же значением для полей username, active и sign_in_count из user1Оператор ..user1 должен стоять последним для указания на получение значений всех оставшихся полей из соответствующих полей в user1, но можно указать значения для любого количества полей в любом порядке, независимо от порядка полей в определении структуры.Заметим, что синтаксис обновления структуры использует = как присваивание. Это связано с перемещением данных, как мы видели в разделе "Способы взаимодействия переменных и данных: перемещение". В этом примере мы больше не можем использовать user1 после создания user2, потому что String в поле username из user1 было перемещено в user2. Если бы мы задали user2 новые значения String для email и username, и при этом использовать только значения active и sign_in_count из user1, то user1 все ещё будет действительным после создания user2. Типы active и sign_in_count являются типами, реализующими типаж Copy, поэтому будет применяться поведение, о котором мы говорили в разделе "Стековые данные:Копирование"Кортежные структуры: структуры без именованных полей длясоздания разных типовRust также поддерживает структуры, похожие на кортежи, которые называютсякортежные структуры. Кортежные структуры обладают дополнительным смыслом,который даёт имя структуры, но при этом не имеют имён, связанных с их полями. Скорее,они просто хранят типы полей. Кортежные структуры полезны, когда вы хотите дать имя всему кортежу и сделать кортеж отличным от других кортежей, и когда именование каждого поля, как в обычной структуре, было бы многословным или избыточным.Чтобы определить кортежную структуру, начните с ключевого слова struct и имени структуры, за которым следуют типы в кортеже. Например, здесь мы определяем и используем две кортежные структуры с именами Color и Point:fn main() { // --snip-- let user2 = User { email: String::from("another@example.com"), ..user1 }; } Обратите внимание, что значения black и origin — это разные типы, потому что они являются экземплярами разных кортежных структур. Каждая определяемая вами структура имеет собственный тип, даже если поля внутри структуры могут иметь одинаковые типы. Например, функция, принимающая параметр типа Color, не может принимать Point в качестве аргумента, даже если оба типа состоят из трёх значений i32. В остальном экземпляры кортежных структур похожи на кортежи в том смысле, что вы можете деструктурировать их на отдельные части и использовать , за которой следует индекс для доступа к отдельному значению.Единично-подобные структуры: структуры без полейТакже можно определять структуры, не имеющие полей! Они называются единично-подобными структурами, поскольку ведут себя аналогично (), единичному типу, о котором мы говорили в разделе "Кортежи". Единично-подобные структуры могут быть полезны, когда требуется реализовать типаж для некоторого типа, но у вас нет данных,которые нужно хранить в самом типе. Мы обсудим типажи в главе 10. Вот пример объявления и создание экземпляра единичной структуры с именем AlwaysEqual:Чтобы определить AlwaysEqual, мы используем ключевое слово struct, желаемое имя,а затем точку с запятой. Нет необходимости в фигурных или круглых скобках! Затем мы можем получить экземпляр AlwaysEqual в переменной subject аналогичным образом:используя имя, которое мы определили, без фигурных и круглых скобок. Представим, что в дальнейшем мы реализуем поведение для этого типа таким образом, что каждый экземпляр AlwaysEqual всегда будет равен каждому экземпляру любого другого типа,возможно, с целью получения ожидаемого результата для тестирования. Для реализации такого поведения нам не нужны никакие данные! В главе 10 вы увидите, как определять черты и реализовывать их для любого типа, включая единично-подобные структуры.Владение данными структурыstructColor(i32, i32, i32); structPoint(i32, i32, i32); fn main() { let black = Color(0, 0, 0); let origin = Point(0, 0, 0); } structAlwaysEqual; fn main() { let subject = AlwaysEqual; } В определении структуры User в листинге 5-1 мы использовали владеющий тип String вместо типа строковой срез &str. Это осознанный выбор, поскольку мы хотим, чтобы каждый экземпляр этой структуры владел всеми своими данными и чтобы эти данные были действительны до тех пор, пока действительна вся структура.Структуры также могут хранить ссылки на данные, принадлежащие кому-то другому,но для этого необходимо использовать возможность Rust время жизни, которую мы обсудим в главе 10. Время жизни гарантирует, что данные, на которые ссылается структура, будут действительны до тех пор, пока существует структура. Допустим,если попытаться сохранить ссылку в структуре без указания времени жизни, как в следующем примере; это не сработает:Имя файла: src/main.rsКомпилятор будет жаловаться на необходимость определения времени жизни ссылок:structUser { active: bool, username: &str, email: &str, sign_in_count: u64, } fn main() { let user1 = User { email: "someone@example.com", username: "someusername123", active: true, sign_in_count: 1, }; } В главе 10 мы обсудим, как исправить эти ошибки, чтобы иметь возможность хранить ссылки в структурах, а пока мы исправим подобные ошибки, используя владеющие типы вроде String вместо ссылок &str$ cargo run Compiling structs v0.1.0 (file:///projects/structs) error[E0106]: missing lifetime specifier --> src/main.rs:3:15 | 3 | username: &str, | ^ expected named lifetime parameter | help: consider introducing a named lifetime parameter | 1 struct User<'a> { 2 | active: bool, 3 username: &'a str, | error[E0106]: missing lifetime specifier --> src/main.rs:4:12 | 4 | email: &str, | ^ expected named lifetime parameter | help: consider introducing a named lifetime parameter | 1 struct User<'a> { 2 | active: bool, 3 | username: &str, 4 email: &'a str, | For more information about this error, try `rustc --explain E0106`. error: could not compile `structs` due to 2 previous errors Пример использования структурЧтобы понять, когда нам может понадобиться использование структур, давайте напишем программу, которая вычисляет площадь прямоугольника. Мы начнём с использования одиночных переменных, а затем будем улучшать программу до использования структур.Давайте создадим новый проект программы при помощи Cargo и назовём его rectangles.Наша программа будет получать на вход длину и ширину прямоугольника в пикселях и затем рассчитывать площадь прямоугольника. Листинг 5-8 показывает один из коротких вариантов кода, который позволит нам сделать именно то, что надо, в файле проектаsrc/main.rs.Файл: src/main.rsЛистинг 5-8: вычисление площади прямоугольника, заданного отдельными переменными ширины ивысотыТеперь запустим программу, используя cargo run:Этот код успешно вычисляет площадь прямоугольника, вызывая функцию area скаждым измерением, но мы можем улучшить его ясность и читабельность.Проблема данного метода очевидна из сигнатуры area:Функция area должна вычислять площадь одного прямоугольника, но функция, которую мы написали, имеет два параметра, и нигде в нашей программе не ясно, что эти параметры взаимосвязаны. Было бы более читабельным и управляемым сгруппировать fn main() { let width1 = 30; let height1 = 50; println!( "The area of the rectangle is {} square pixels.", area(width1, height1) ); } fn area(width: u32, height: u32) -> u32 { width * height } $ cargo run Compiling rectangles v0.1.0 (file:///projects/rectangles) Finished dev [unoptimized + debuginfo] target(s) in 0.42s Running `target/debug/rectangles` The area of the rectangle is 1500 square pixels. fn area(width: u32, height: u32) -> u32 { ширину и высоту вместе. В разделе «Кортежи» главы 3 мы уже обсуждали один из способов сделать это — использовать кортежи.Рефакторинг при помощи кортежейЛистинг 5-9 — это другая версия программы, использующая кортежи.Файл: src/main.rsЛистинг 5-9: определение ширины и высоты прямоугольника с помощью кортежаС одной стороны, эта программа лучше. Кортежи позволяют добавить немного структуры, и теперь мы передаём только один аргумент. Но с другой стороны, эта версия менее понятна: кортежи не называют свои элементы, поэтому нам приходится индексировать части кортежа, что делает наше вычисление менее очевидным.Если мы перепутаем местами ширину с высотой при расчёте площади, то это не имеет значения. Но если мы хотим нарисовать прямоугольник на экране, то это уже будет важно! Мы должны помнить, что ширина width находится в кортеже с индексом 0, а высота height — с индексом 1. Если кто-то другой поработал бы с кодом, ему бы пришлось разобраться в этом и также помнить про порядок. Легко забыть и перепутать эти значения — и это вызовет ошибки, потому что данный код не передаёт наши намерения.Рефакторинг при помощи структур: добавим больше смыслаМы используем структуры, чтобы добавить смысл данным при помощи назначения им осмысленных имён . Мы можем переделать используемый кортеж в структуру с единым именем для сущности и частными названиями её частей, как показано в листинге 5-10.Файл: src/main.rs fn main() { let rect1 = (30, 50); println!( "The area of the rectangle is {} square pixels.", area(rect1) ); } fn area(dimensions: (u32, u32)) -> u32 { dimensions.0 * dimensions.1} Листинг 5-10: определение структуры RectangleЗдесь мы определили структуру и дали ей имя Rectangle. Внутри фигурных скобок определили поля как width и height, оба — типа u32. Затем в main создали конкретный экземпляр Rectangle с шириной в 30 и высотой в 50 единиц.Наша функция area теперь определена с одним параметром, названным rectangle, чей тип является неизменяемым заимствованием структуры Rectangle. Как упоминалось в главе 4, необходимо заимствовать структуру, а не передавать её во владение. Таким образом функция main сохраняет rect1 в собственности и может использовать еёдальше. По этой причине мы и используем & в сигнатуре и в месте вызова функции.Функция area получает доступ к полям width и height экземпляра Rectangle (обратите внимание, что доступ к полям заимствованного экземпляра структуры не приводит к перемещению значений полей, поэтому вы часто видите заимствования структур). Наша сигнатура функции для area теперь говорит именно то, что мы имеем в виду: вычислить площадь Rectangle, используя его поля width и height. Это означает, что ширина и высота связаны друг с другом, и даёт описательные имена значениям, а не использует значения индекса кортежа 0 и 1. Это торжество ясности.Добавление полезной функциональности при помощи выводимых1 ... 6 7 8 9 10 11 12 13 ... 62

help: use `impl Fn(i32) -> i32` as the return type, as all return paths are of type `[closure@src/lib.rs:2:5: 2:14]`, which implements `Fn(i32) -> i32` | 1 | fn returns_closure() -> impl Fn(i32) -> i32 { |

В листинге 17-11 показано, что мы хотим иметь возможность вызывать метод add_text и
передать ему
&str
, которое добавляется к текстовому содержимому записи блога. Мы реализуем эту возможность как метод, а не делаем поле content публично доступным,
используя pub
. Это означает, что позже мы сможем написать метод, который будет контролировать, как именно читаются данные из поля content
. Метод add_text довольно прост, поэтому давайте добавим его реализацию в блок impl Post листинга 17-
13 :
Файл: src/lib.rs
Листинг 17-13. Реализация
add_text
для добавления текста к
content
(содержимому записи)
Метод add_text принимает изменяемую ссылку на self
, потому что мы меняем экземпляр
Post
, для которого вызываем add_text
. Затем мы вызываем push_str для
String у поля content и передаём text аргументом для добавления к сохранённому content
. Это поведение не зависит от состояния, в котором находится запись, таким образом оно не является частью шаблона "Состояние". Метод add_text вообще не взаимодействует с полем state
, но это часть поведения, которое мы хотим поддерживать.
Убедимся, что содержание черновика будет пустым
Даже после того, как мы вызвали add_text и добавили некоторый контент в нашу запись, мы хотим, чтобы метод content возвращал пустой фрагмент строки, так как запись всё ещё находится в черновом состоянии, как это показано в строке 7 листинга
17-11. А пока давайте реализуем метод content наиболее простым способом, который будет удовлетворять этому требованию: будем всегда возвращать пустой фрагмент строки. Мы изменим код позже, как только реализуем возможность изменить состояние записи, чтобы она могла бы быть опубликована. Пока что записи могут находиться только в черновом состоянии, поэтому содержимое записи всегда должно быть пустым.
Листинг 17-14 показывает такую реализацию-заглушку:
Файл: src/lib.rs impl
Post {
// --snip-- pub fn add_text
(&
mut self
, text: &
str
) { self
.content.push_str(text);
}
}

Листинг 17-14. Добавление реализации-заглушки для метода
content
в
Post
, которая всегда возвращает
пустой фрагмент строки.
С добавленным таким образом методом content всё в листинге 17-11 работает, как задумано, вплоть до строки 7.
Запрос на проверку записи меняет её состояние
Далее нам нужно добавить функциональность для запроса проверки записи, который должен изменить её состояние с
Draft на
PendingReview
. Листинг 17-15 показывает такой код:
Файл: src/lib.rs
Листинг 17-15. Реализация методов
request_review
в структуре
Post
и типаже
State impl
Post {
// --snip-- pub fn content
(&
self
) -> &
str
{
""
}
} impl
Post {
// --snip-- pub fn request_review
(&
mut self
) { if let
Some
(s) = self
.state.take() { self
.state =
Some
(s.request_review())
}
}
} trait
State
{ fn request_review
(
self
:
Box
<
Self
>) ->
Box
<
dyn
State>;
} struct
Draft
{} impl
State for
Draft { fn request_review
(
self
:
Box
<
Self
>) ->
Box
<
dyn
State> {
Box
::new(PendingReview {})
}
} struct
PendingReview
{} impl
State for
PendingReview { fn request_review
(
self
:
Box
<
Self
>) ->
Box
<
dyn
State> { self
}
}

Мы добавляем в
Post публичный метод с именем request_review
("запросить проверку"), который будет принимать изменяемую ссылку на self
. Затем мы вызываем внутренний метод request_review для текущего состояния
Post
, и этот второй метод request_review поглощает текущее состояние и возвращает новое состояние.
Мы добавляем метод request_review в типаж
State
; все типы, реализующие этот типаж,
теперь должны будут реализовать метод request_review
. Обратите внимание, что вместо self
,
&self или
&mut self в качестве первого параметра метода у нас указан self: Box
. Этот синтаксис означает, что метод действителен только при его вызове с обёрткой
Box
, содержащей наш тип. Этот синтаксис становится владельцем
Box
, делая старое состояние недействительным, поэтому значение состояния
Post может быть преобразовано в новое состояние.
Чтобы поглотить старое состояние, метод request_review должен стать владельцем значения состояния. Это место, где приходит на помощь тип
Option поля state записи
Post
: мы вызываем метод take
, чтобы забрать значение
Some из поля state и
оставить вместо него значение
None
, потому что Rust не позволяет иметь неинициализированные поля в структурах. Это позволяет перемещать значение state из
Post
, а не заимствовать его. Затем мы установим новое значение state как результат этой операции.
Нам нужно временно установить state в
None
, вместо того, чтобы установить его напрямую с помощью кода вроде self.state = self.state.request_review();
. Нам нужно завладеть значением поля state
. Это даст нам гарантию, что
Post не сможет использовать старое значение state после того, как мы преобразовали его в новое состояние.
Метод request_review в
Draft должен вернуть новый экземпляр новой структуры
PendingReview
, обёрнутый в Box. Эта структура будет представлять состояние, в котором запись ожидает проверки. Структура
PendingReview также реализует метод request_review
, но не выполняет никаких преобразований. Она возвращает сама себя,
потому что, когда мы запрашиваем проверку записи, уже находящейся в состоянии
PendingReview
, она всё так же должна продолжать оставаться в состоянии
PendingReview
Теперь мы начинаем видеть преимущества шаблона "Состояние": метод request_review для
Post одинаков, он не зависит от значения state
. Каждое состояние само несёт ответственность за свои действия.
Оставим метод content у
Post таким как есть, возвращающим пустой фрагмент строки.
Теперь мы можем иметь
Post как в состоянии
PendingReview
, так и в состоянии
Draft
,
но мы хотим получить такое же поведение в состоянии
PendingReview
. Листинг 17-11
теперь работает до строки 10!

Добавление approve для изменения поведения content
Метод approve
("одобрить") будет аналогичен методу request_review
: он будет устанавливать у state значение, которое должна иметь запись при её одобрении, как показано в листинге 17-16:
Файл: src/lib.rs
Листинг 17-16. Реализация метода
approve
для типа
Post
и типажа
State impl
Post {
// --snip-- pub fn approve
(&
mut self
) { if let
Some
(s) = self
.state.take() { self
.state =
Some
(s.approve())
}
}
} trait
State
{ fn request_review
(
self
:
Box
<
Self
>) ->
Box
<
dyn
State>; fn approve
(
self
:
Box
<
Self
>) ->
Box
<
dyn
State>;
} struct
Draft
{} impl
State for
Draft {
// --snip-- fn approve
(
self
:
Box
<
Self
>) ->
Box
<
dyn
State> { self
}
} struct
PendingReview
{} impl
State for
PendingReview {
// --snip-- fn approve
(
self
:
Box
<
Self
>) ->
Box
<
dyn
State> {
Box
::new(Published {})
}
} struct
Published
{} impl
State for
Published { fn request_review
(
self
:
Box
<
Self
>) ->
Box
<
dyn
State> { self
} fn approve
(
self
:
Box
<
Self
>) ->
Box
<
dyn
State> { self
}
}

Мы добавляем метод approve в типаж
State
, добавляем новую структуру, которая реализует этот типаж
State и структуру для состояния
Published
Подобно тому, как работает request_review для
PendingReview
, если мы вызовем метод approve для
Draft
, он не будет иметь никакого эффекта, потому что approve вернёт self
. Когда мы вызываем для
PendingReview метод approve
, то он возвращает новый упакованный экземпляр структуры
Published
. Структура
Published реализует трейт
State
, и как для метода request_review
, так и для метода approve она возвращает себя,
потому что в этих случаях запись должна оставаться в состоянии
Published
Теперь нам нужно обновить метод content для
Post
. Мы хотим, чтобы значение,
возвращаемое из content
, зависело от текущего состояния
Post
, поэтому мы собираемся перенести часть функциональности
Post в метод content
, заданный для state
, как показано в листинге 17.17:
Файл: src/lib.rs
Листинг 17-17: Обновление метода
content
в структуре
Post
для делегирования части функциональности
методу
content
структуры
State
Поскольку наша цель состоит в том, чтобы сохранить все эти действия внутри структур,
реализующих типаж
State
, мы вызываем метод content у значения в поле state и
передаём экземпляр публикации (то есть self
) в качестве аргумента. Затем мы возвращаем значение, которое нам выдаёт вызов метода content поля state
Мы вызываем метод as_ref у
Option
, потому что нам нужна ссылка на значение внутри
Option
, а не владение значением. Поскольку state является типом
OptionState>>
, то при вызове метода as_ref возвращается
Option<&Box>
. Если бы мы не вызывали as_ref
, мы бы получили ошибку, потому что мы не можем переместить state из заимствованного параметра
&self функции.
Затем мы вызываем метод unwrap
. Мы знаем, что этот метод здесь никогда не приведёт к аварийному завершению программы, так все методы
Post устроены таким образом,
что после их выполнения, в поле state всегда содержится значение
Some
. Это один из случаев, про которых мы говорили в разделе "Случаи, когда у вас больше информации,
чем у компилятора"
главы 9 - случай, когда мы знаем, что значение
None никогда не встретится, даже если компилятор не может этого понять.
impl
Post {
// --snip-- pub fn content
(&
self
) -> &
str
{ self
.state.as_ref().unwrap().content(
self
)
}
// --snip--
}

Теперь, когда мы вызываем content у типа
&Box
, в действие вступает принудительное приведение (deref coercion) для
&
и
Box
, поэтому в конечном итоге метод content будет вызван для типа, который реализует типаж
State
. Это означает,
что нам нужно добавить метод content в определение типажа
State
, и именно там мы поместим логику для определения того, какое содержимое возвращать, в зависимости от текущего состояния, как показано в листинге 17-18:
Файл: src/lib.rs
Листинг 17-18. Добавление метода
content
в трейт
State
Мы добавляем реализацию по умолчанию метода content
, который возвращает пустой фрагмент строки. Это означает, что нам не придётся реализовывать content в
структурах
Draft и
PendingReview
. Структура
Published будет переопределять метод content и вернёт значение из post.content
Обратите внимание, что для этого метода нам нужны аннотации времени жизни, как мы обсуждали в главе 10. Мы берём ссылку на post в качестве аргумента и возвращаем ссылку на часть этого post
, поэтому время жизни возвращённой ссылки связано с временем жизни аргумента post
И вот, мы закончили - теперь всё из листинга 17-11 работает! Мы реализовали шаблон "Состояние", определяющий правила процесса работы с записью в блоге. Логика,
связанная с этими правилами, находится в объектах состояний, а не разбросана по всей структуре
Post
Почему не перечисление?
Возможно, вам было интересно, почему мы не использовали enum с различными возможными состояниями записи в качестве вариантов. Это, безусловно, одно из возможных решений. Попробуйте его реализовать и сравните конечные trait
State
{
// --snip-- fn content
<
'a
>(&
self
, post: &
'a
Post) -> &
'a str
{
""
}
}
// --snip-- struct
Published
{} impl
State for
Published {
// --snip-- fn content
<
'a
>(&
self
, post: &
'a
Post) -> &
'a str
{
&post.content
}
}

результаты, чтобы выбрать, какой из вариантов вам больше нравится! Одним из недостатков использования перечисления является то, что в каждом месте, где проверяется значение перечисления, потребуется выражение match или что-то подобное для обработки всех возможных вариантов. Возможно в этом случае нам придётся повторять больше кода, чем это было в решении с типаж-объектом.
Компромиссы шаблона "Состояние"
Мы показали, что Rust способен реализовать объектно-ориентированный шаблон "Состояние" для инкапсуляции различных типов поведения, которые должна иметь запись в каждом состоянии. Методы в
Post ничего не знают о различных видах поведения. При такой организации кода, нам достаточно взглянуть только на один его участок, чтобы узнать отличия в поведении опубликованной публикации: в реализацию типажа
State у структуры
Published
Если бы мы собирались создать альтернативную реализацию, не использующую шаблон "Состояние", мы могли бы использовать выражения match в методах структуры
Post или даже в коде main
, для проверки состояния записи и изменения её поведения в этих местах. Это означало бы, что нам пришлось бы анализировать несколько участков кода,
чтобы понять что как ведёт себя сообщение в опубликованном состоянии! Если бы мы решили добавить ещё состояний, стало бы ещё хуже: каждому этих выражений match потребовались бы дополнительные ответвления.
С помощью шаблона "Состояние" методы
Post и участки, где мы используем
Post
, не требуют использования выражений match
, а для добавления нового состояния нужно только добавить новую структуру и реализовать методы типажа у одной этой структуры.
Реализацию с использованием шаблона "Состояние" легко расширить для добавления новой функциональности. Чтобы увидеть, как легко поддерживать код, использующий данный шаблон, попробуйте выполнить некоторые из предложений ниже:
Добавьте метод reject
, который изменяет состояние публикации с
PendingReview обратно на
Draft
Потребуйте два вызова метода approve
, прежде чем переводить состояние в
Published
Разрешите пользователям добавлять текстовое содержимое только тогда, когда публикация находится в состоянии
Draft
. Подсказка: пусть объект состояния решает, можно ли менять содержимое, но не отвечает за изменение
Post
Одним из недостатков шаблона "Состояние" является то, что поскольку состояния сами реализуют переходы между собой, некоторые из состояний получаются связанными друг с другом. Если мы добавим другое состояние между
PendingReview и
Published
,
например
Scheduled
("запланировано"), то придётся изменить код в
PendingReview
,
чтобы оно теперь переходило в
Scheduled
. Если бы не нужно было менять

PendingReview при добавлении нового состояния, было бы меньше работы, но это означало бы, что мы переходим на другой шаблон проектирования.
Другим недостатком является то, что мы продублировали некоторую логику. Чтобы устранить некоторое дублирование, мы могли бы попытаться сделать реализации по умолчанию для методов request_review и approve типажа
State
, которые возвращают self
; однако это нарушило бы безопасность объекта, потому что типаж не знает, каким конкретно будет self
. Мы хотим иметь возможность использовать
State в качестве типаж-объекта, поэтому нам нужно, чтобы его методы были объектно-безопасными.
Другое дублирование включает в себя схожие реализации методов request_review и approve у
Post
. Оба метода делегируют реализации одного и того же метода значению поля state типа
Option и устанавливают результатом новое значение поля state
. Если бы у
Post было много методов, которые следовали этому шаблону, мы могли бы рассмотреть определение макроса для устранения повторения (смотри раздел "Макросы"
в главе 19).
Реализуя шаблон "Состояние" точно так, как он определён для объектно- ориентированных языков, мы не настолько полно используем преимущества Rust, как могли бы. Давайте посмотрим на некоторые изменения, которые мы можем внести в крейт blog
, чтобы недопустимые состояния и переходы превратить в ошибки времени компиляции.

1 ... 44 45 46 47 48 49 50 51 ... 62

Смотрите также файлы

Выполнение практических заданий по дисциплине административное право.docx

Лабораторная работа 1 Кобеидзе Николай Пример П1.docx

Рабочая программа по английскому языку.docx

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

Задача 3 Общин положения.docx

Файл: Язык программирования Rust.pdf

Смотрите также файлы

Информация

Списки файлов

Дополнительно