889 lines
50 KiB
HTML
889 lines
50 KiB
HTML
<!DOCTYPE html>
|
||
<html lang="en">
|
||
<head>
|
||
<meta charset="UTF-8">
|
||
<title>Implementing an Object-Oriented Design Pattern</title>
|
||
</head>
|
||
<body>
|
||
<h2 id="implementing-an-object-oriented-design-pattern"><a class="header" href="#implementing-an-object-oriented-design-pattern">Implementing an Object-Oriented Design Pattern</a></h2>
|
||
<p>The <em>state pattern</em> is an object-oriented design pattern. The crux of the
|
||
pattern is that we define a set of states a value can have internally. The
|
||
states are represented by a set of <em>state objects</em>, and the value’s behavior
|
||
changes based on its state. We’re going to work through an example of a blog
|
||
post struct that has a field to hold its state, which will be a state object
|
||
from the set “draft,” “review,” or “published.”</p>
|
||
<p>The state objects share functionality: In Rust, of course, we use structs and
|
||
traits rather than objects and inheritance. Each state object is responsible
|
||
for its own behavior and for governing when it should change into another
|
||
state. The value that holds a state object knows nothing about the different
|
||
behavior of the states or when to transition between states.</p>
|
||
<p>The advantage of using the state pattern is that, when the business
|
||
requirements of the program change, we won’t need to change the code of the
|
||
value holding the state or the code that uses the value. We’ll only need to
|
||
update the code inside one of the state objects to change its rules or perhaps
|
||
add more state objects.</p>
|
||
<p>First, we’re going to implement the state pattern in a more traditional
|
||
object-oriented way. Then, we’ll use an approach that’s a bit more natural in
|
||
Rust. Let’s dig in to incrementally implement a blog post workflow using the
|
||
state pattern.</p>
|
||
<p>The final functionality will look like this:</p>
|
||
<ol>
|
||
<li>A blog post starts as an empty draft.</li>
|
||
<li>When the draft is done, a review of the post is requested.</li>
|
||
<li>When the post is approved, it gets published.</li>
|
||
<li>Only published blog posts return content to print so that unapproved posts
|
||
can’t accidentally be published.</li>
|
||
</ol>
|
||
<p>Any other changes attempted on a post should have no effect. For example, if we
|
||
try to approve a draft blog post before we’ve requested a review, the post
|
||
should remain an unpublished draft.</p>
|
||
<!-- Old headings. Do not remove or links may break. -->
|
||
<p><a id="a-traditional-object-oriented-attempt"></a></p>
|
||
<h3 id="attempting-traditional-object-oriented-style"><a class="header" href="#attempting-traditional-object-oriented-style">Attempting Traditional Object-Oriented Style</a></h3>
|
||
<p>There are infinite ways to structure code to solve the same problem, each with
|
||
different trade-offs. This section’s implementation is more of a traditional
|
||
object-oriented style, which is possible to write in Rust, but doesn’t take
|
||
advantage of some of Rust’s strengths. Later, we’ll demonstrate a different
|
||
solution that still uses the object-oriented design pattern but is structured
|
||
in a way that might look less familiar to programmers with object-oriented
|
||
experience. We’ll compare the two solutions to experience the trade-offs of
|
||
designing Rust code differently than code in other languages.</p>
|
||
<p>Listing 18-11 shows this workflow in code form: This is an example usage of the
|
||
API we’ll implement in a library crate named <code>blog</code>. This won’t compile yet
|
||
because we haven’t implemented the <code>blog</code> crate.</p>
|
||
<figure class="listing" id="listing-18-11">
|
||
<span class="file-name">Filename: src/main.rs</span>
|
||
<pre><code class="language-rust ignore does_not_compile">use blog::Post;
|
||
|
||
fn main() {
|
||
let mut post = Post::new();
|
||
|
||
post.add_text("I ate a salad for lunch today");
|
||
assert_eq!("", post.content());
|
||
|
||
post.request_review();
|
||
assert_eq!("", post.content());
|
||
|
||
post.approve();
|
||
assert_eq!("I ate a salad for lunch today", post.content());
|
||
}</code></pre>
|
||
<figcaption><a href="#listing-18-11">Listing 18-11</a>: Code that demonstrates the desired behavior we want our <code>blog</code> crate to have</figcaption>
|
||
</figure>
|
||
<p>We want to allow the user to create a new draft blog post with <code>Post::new</code>. We
|
||
want to allow text to be added to the blog post. If we try to get the post’s
|
||
content immediately, before approval, we shouldn’t get any text because the
|
||
post is still a draft. We’ve added <code>assert_eq!</code> in the code for demonstration
|
||
purposes. An excellent unit test for this would be to assert that a draft blog
|
||
post returns an empty string from the <code>content</code> method, but we’re not going to
|
||
write tests for this example.</p>
|
||
<p>Next, we want to enable a request for a review of the post, and we want
|
||
<code>content</code> to return an empty string while waiting for the review. When the post
|
||
receives approval, it should get published, meaning the text of the post will
|
||
be returned when <code>content</code> is called.</p>
|
||
<p>Notice that the only type we’re interacting with from the crate is the <code>Post</code>
|
||
type. This type will use the state pattern and will hold a value that will be
|
||
one of three state objects representing the various states a post can be
|
||
in—draft, review, or published. Changing from one state to another will be
|
||
managed internally within the <code>Post</code> type. The states change in response to the
|
||
methods called by our library’s users on the <code>Post</code> instance, but they don’t
|
||
have to manage the state changes directly. Also, users can’t make a mistake
|
||
with the states, such as publishing a post before it’s reviewed.</p>
|
||
<!-- Old headings. Do not remove or links may break. -->
|
||
<p><a id="defining-post-and-creating-a-new-instance-in-the-draft-state"></a></p>
|
||
<h4 id="defining-post-and-creating-a-new-instance"><a class="header" href="#defining-post-and-creating-a-new-instance">Defining <code>Post</code> and Creating a New Instance</a></h4>
|
||
<p>Let’s get started on the implementation of the library! We know we need a
|
||
public <code>Post</code> struct that holds some content, so we’ll start with the
|
||
definition of the struct and an associated public <code>new</code> function to create an
|
||
instance of <code>Post</code>, as shown in Listing 18-12. We’ll also make a private
|
||
<code>State</code> trait that will define the behavior that all state objects for a <code>Post</code>
|
||
must have.</p>
|
||
<p>Then, <code>Post</code> will hold a trait object of <code>Box<dyn State></code> inside an <code>Option<T></code>
|
||
in a private field named <code>state</code> to hold the state object. You’ll see why the
|
||
<code>Option<T></code> is necessary in a bit.</p>
|
||
<figure class="listing" id="listing-18-12">
|
||
<span class="file-name">Filename: src/lib.rs</span>
|
||
<pre><code class="language-rust noplayground">pub struct Post {
|
||
state: Option<Box<dyn State>>,
|
||
content: String,
|
||
}
|
||
|
||
impl Post {
|
||
pub fn new() -> Post {
|
||
Post {
|
||
state: Some(Box::new(Draft {})),
|
||
content: String::new(),
|
||
}
|
||
}
|
||
}
|
||
|
||
trait State {}
|
||
|
||
struct Draft {}
|
||
|
||
impl State for Draft {}</code></pre>
|
||
<figcaption><a href="#listing-18-12">Listing 18-12</a>: Definition of a <code>Post</code> struct and a <code>new</code> function that creates a new <code>Post</code> instance, a <code>State</code> trait, and a <code>Draft</code> struct</figcaption>
|
||
</figure>
|
||
<p>The <code>State</code> trait defines the behavior shared by different post states. The
|
||
state objects are <code>Draft</code>, <code>PendingReview</code>, and <code>Published</code>, and they will all
|
||
implement the <code>State</code> trait. For now, the trait doesn’t have any methods, and
|
||
we’ll start by defining just the <code>Draft</code> state because that is the state we
|
||
want a post to start in.</p>
|
||
<p>When we create a new <code>Post</code>, we set its <code>state</code> field to a <code>Some</code> value that
|
||
holds a <code>Box</code>. This <code>Box</code> points to a new instance of the <code>Draft</code> struct. This
|
||
ensures that whenever we create a new instance of <code>Post</code>, it will start out as
|
||
a draft. Because the <code>state</code> field of <code>Post</code> is private, there is no way to
|
||
create a <code>Post</code> in any other state! In the <code>Post::new</code> function, we set the
|
||
<code>content</code> field to a new, empty <code>String</code>.</p>
|
||
<h4 id="storing-the-text-of-the-post-content"><a class="header" href="#storing-the-text-of-the-post-content">Storing the Text of the Post Content</a></h4>
|
||
<p>We saw in Listing 18-11 that we want to be able to call a method named
|
||
<code>add_text</code> and pass it a <code>&str</code> that is then added as the text content of the
|
||
blog post. We implement this as a method, rather than exposing the <code>content</code>
|
||
field as <code>pub</code>, so that later we can implement a method that will control how
|
||
the <code>content</code> field’s data is read. The <code>add_text</code> method is pretty
|
||
straightforward, so let’s add the implementation in Listing 18-13 to the <code>impl Post</code> block.</p>
|
||
<figure class="listing" id="listing-18-13">
|
||
<span class="file-name">Filename: src/lib.rs</span>
|
||
<pre><code class="language-rust noplayground"><span class="boring">pub struct Post {
|
||
</span><span class="boring"> state: Option<Box<dyn State>>,
|
||
</span><span class="boring"> content: String,
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span>impl Post {
|
||
// --snip--
|
||
<span class="boring"> pub fn new() -> Post {
|
||
</span><span class="boring"> Post {
|
||
</span><span class="boring"> state: Some(Box::new(Draft {})),
|
||
</span><span class="boring"> content: String::new(),
|
||
</span><span class="boring"> }
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span> pub fn add_text(&mut self, text: &str) {
|
||
self.content.push_str(text);
|
||
}
|
||
}
|
||
<span class="boring">
|
||
</span><span class="boring">trait State {}
|
||
</span><span class="boring">
|
||
</span><span class="boring">struct Draft {}
|
||
</span><span class="boring">
|
||
</span><span class="boring">impl State for Draft {}</span></code></pre>
|
||
<figcaption><a href="#listing-18-13">Listing 18-13</a>: Implementing the <code>add_text</code> method to add text to a post’s <code>content</code></figcaption>
|
||
</figure>
|
||
<p>The <code>add_text</code> method takes a mutable reference to <code>self</code> because we’re
|
||
changing the <code>Post</code> instance that we’re calling <code>add_text</code> on. We then call
|
||
<code>push_str</code> on the <code>String</code> in <code>content</code> and pass the <code>text</code> argument to add to
|
||
the saved <code>content</code>. This behavior doesn’t depend on the state the post is in,
|
||
so it’s not part of the state pattern. The <code>add_text</code> method doesn’t interact
|
||
with the <code>state</code> field at all, but it is part of the behavior we want to
|
||
support.</p>
|
||
<!-- Old headings. Do not remove or links may break. -->
|
||
<p><a id="ensuring-the-content-of-a-draft-post-is-empty"></a></p>
|
||
<h4 id="ensuring-that-the-content-of-a-draft-post-is-empty"><a class="header" href="#ensuring-that-the-content-of-a-draft-post-is-empty">Ensuring That the Content of a Draft Post Is Empty</a></h4>
|
||
<p>Even after we’ve called <code>add_text</code> and added some content to our post, we still
|
||
want the <code>content</code> method to return an empty string slice because the post is
|
||
still in the draft state, as shown by the first <code>assert_eq!</code> in Listing 18-11.
|
||
For now, let’s implement the <code>content</code> method with the simplest thing that will
|
||
fulfill this requirement: always returning an empty string slice. We’ll change
|
||
this later once we implement the ability to change a post’s state so that it
|
||
can be published. So far, posts can only be in the draft state, so the post
|
||
content should always be empty. Listing 18-14 shows this placeholder
|
||
implementation.</p>
|
||
<figure class="listing" id="listing-18-14">
|
||
<span class="file-name">Filename: src/lib.rs</span>
|
||
<pre><code class="language-rust noplayground"><span class="boring">pub struct Post {
|
||
</span><span class="boring"> state: Option<Box<dyn State>>,
|
||
</span><span class="boring"> content: String,
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span>impl Post {
|
||
// --snip--
|
||
<span class="boring"> pub fn new() -> Post {
|
||
</span><span class="boring"> Post {
|
||
</span><span class="boring"> state: Some(Box::new(Draft {})),
|
||
</span><span class="boring"> content: String::new(),
|
||
</span><span class="boring"> }
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> pub fn add_text(&mut self, text: &str) {
|
||
</span><span class="boring"> self.content.push_str(text);
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span> pub fn content(&self) -> &str {
|
||
""
|
||
}
|
||
}
|
||
<span class="boring">
|
||
</span><span class="boring">trait State {}
|
||
</span><span class="boring">
|
||
</span><span class="boring">struct Draft {}
|
||
</span><span class="boring">
|
||
</span><span class="boring">impl State for Draft {}</span></code></pre>
|
||
<figcaption><a href="#listing-18-14">Listing 18-14</a>: Adding a placeholder implementation for the <code>content</code> method on <code>Post</code> that always returns an empty string slice</figcaption>
|
||
</figure>
|
||
<p>With this added <code>content</code> method, everything in Listing 18-11 through the first
|
||
<code>assert_eq!</code> works as intended.</p>
|
||
<!-- Old headings. Do not remove or links may break. -->
|
||
<p><a id="requesting-a-review-of-the-post-changes-its-state"></a>
|
||
<a id="requesting-a-review-changes-the-posts-state"></a></p>
|
||
<h4 id="requesting-a-review-which-changes-the-posts-state"><a class="header" href="#requesting-a-review-which-changes-the-posts-state">Requesting a Review, Which Changes the Post’s State</a></h4>
|
||
<p>Next, we need to add functionality to request a review of a post, which should
|
||
change its state from <code>Draft</code> to <code>PendingReview</code>. Listing 18-15 shows this code.</p>
|
||
<figure class="listing" id="listing-18-15">
|
||
<span class="file-name">Filename: src/lib.rs</span>
|
||
<pre><code class="language-rust noplayground"><span class="boring">pub struct Post {
|
||
</span><span class="boring"> state: Option<Box<dyn State>>,
|
||
</span><span class="boring"> content: String,
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span>impl Post {
|
||
// --snip--
|
||
<span class="boring"> pub fn new() -> Post {
|
||
</span><span class="boring"> Post {
|
||
</span><span class="boring"> state: Some(Box::new(Draft {})),
|
||
</span><span class="boring"> content: String::new(),
|
||
</span><span class="boring"> }
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> pub fn add_text(&mut self, text: &str) {
|
||
</span><span class="boring"> self.content.push_str(text);
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> pub fn content(&self) -> &str {
|
||
</span><span class="boring"> ""
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span> 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
|
||
}
|
||
}</code></pre>
|
||
<figcaption><a href="#listing-18-15">Listing 18-15</a>: Implementing <code>request_review</code> methods on <code>Post</code> and the <code>State</code> trait</figcaption>
|
||
</figure>
|
||
<p>We give <code>Post</code> a public method named <code>request_review</code> that will take a mutable
|
||
reference to <code>self</code>. Then, we call an internal <code>request_review</code> method on the
|
||
current state of <code>Post</code>, and this second <code>request_review</code> method consumes the
|
||
current state and returns a new state.</p>
|
||
<p>We add the <code>request_review</code> method to the <code>State</code> trait; all types that
|
||
implement the trait will now need to implement the <code>request_review</code> method.
|
||
Note that rather than having <code>self</code>, <code>&self</code>, or <code>&mut self</code> as the first
|
||
parameter of the method, we have <code>self: Box<Self></code>. This syntax means the
|
||
method is only valid when called on a <code>Box</code> holding the type. This syntax takes
|
||
ownership of <code>Box<Self></code>, invalidating the old state so that the state value of
|
||
the <code>Post</code> can transform into a new state.</p>
|
||
<p>To consume the old state, the <code>request_review</code> method needs to take ownership
|
||
of the state value. This is where the <code>Option</code> in the <code>state</code> field of <code>Post</code>
|
||
comes in: We call the <code>take</code> method to take the <code>Some</code> value out of the <code>state</code>
|
||
field and leave a <code>None</code> in its place because Rust doesn’t let us have
|
||
unpopulated fields in structs. This lets us move the <code>state</code> value out of
|
||
<code>Post</code> rather than borrowing it. Then, we’ll set the post’s <code>state</code> value to
|
||
the result of this operation.</p>
|
||
<p>We need to set <code>state</code> to <code>None</code> temporarily rather than setting it directly
|
||
with code like <code>self.state = self.state.request_review();</code> to get ownership of
|
||
the <code>state</code> value. This ensures that <code>Post</code> can’t use the old <code>state</code> value
|
||
after we’ve transformed it into a new state.</p>
|
||
<p>The <code>request_review</code> method on <code>Draft</code> returns a new, boxed instance of a new
|
||
<code>PendingReview</code> struct, which represents the state when a post is waiting for a
|
||
review. The <code>PendingReview</code> struct also implements the <code>request_review</code> method
|
||
but doesn’t do any transformations. Rather, it returns itself because when we
|
||
request a review on a post already in the <code>PendingReview</code> state, it should stay
|
||
in the <code>PendingReview</code> state.</p>
|
||
<p>Now we can start seeing the advantages of the state pattern: The
|
||
<code>request_review</code> method on <code>Post</code> is the same no matter its <code>state</code> value. Each
|
||
state is responsible for its own rules.</p>
|
||
<p>We’ll leave the <code>content</code> method on <code>Post</code> as is, returning an empty string
|
||
slice. We can now have a <code>Post</code> in the <code>PendingReview</code> state as well as in the
|
||
<code>Draft</code> state, but we want the same behavior in the <code>PendingReview</code> state.
|
||
Listing 18-11 now works up to the second <code>assert_eq!</code> call!</p>
|
||
<!-- Old headings. Do not remove or links may break. -->
|
||
<p><a id="adding-the-approve-method-that-changes-the-behavior-of-content"></a>
|
||
<a id="adding-approve-to-change-the-behavior-of-content"></a></p>
|
||
<h4 id="adding-approve-to-change-contents-behavior"><a class="header" href="#adding-approve-to-change-contents-behavior">Adding <code>approve</code> to Change <code>content</code>’s Behavior</a></h4>
|
||
<p>The <code>approve</code> method will be similar to the <code>request_review</code> method: It will
|
||
set <code>state</code> to the value that the current state says it should have when that
|
||
state is approved, as shown in Listing 18-16.</p>
|
||
<figure class="listing" id="listing-18-16">
|
||
<span class="file-name">Filename: src/lib.rs</span>
|
||
<pre><code class="language-rust noplayground"><span class="boring">pub struct Post {
|
||
</span><span class="boring"> state: Option<Box<dyn State>>,
|
||
</span><span class="boring"> content: String,
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span>impl Post {
|
||
// --snip--
|
||
<span class="boring"> pub fn new() -> Post {
|
||
</span><span class="boring"> Post {
|
||
</span><span class="boring"> state: Some(Box::new(Draft {})),
|
||
</span><span class="boring"> content: String::new(),
|
||
</span><span class="boring"> }
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> pub fn add_text(&mut self, text: &str) {
|
||
</span><span class="boring"> self.content.push_str(text);
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> pub fn content(&self) -> &str {
|
||
</span><span class="boring"> ""
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> pub fn request_review(&mut self) {
|
||
</span><span class="boring"> if let Some(s) = self.state.take() {
|
||
</span><span class="boring"> self.state = Some(s.request_review())
|
||
</span><span class="boring"> }
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span> 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--
|
||
<span class="boring"> fn request_review(self: Box<Self>) -> Box<dyn State> {
|
||
</span><span class="boring"> Box::new(PendingReview {})
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span> fn approve(self: Box<Self>) -> Box<dyn State> {
|
||
self
|
||
}
|
||
}
|
||
|
||
struct PendingReview {}
|
||
|
||
impl State for PendingReview {
|
||
// --snip--
|
||
<span class="boring"> fn request_review(self: Box<Self>) -> Box<dyn State> {
|
||
</span><span class="boring"> self
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span> 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
|
||
}
|
||
}</code></pre>
|
||
<figcaption><a href="#listing-18-16">Listing 18-16</a>: Implementing the <code>approve</code> method on <code>Post</code> and the <code>State</code> trait</figcaption>
|
||
</figure>
|
||
<p>We add the <code>approve</code> method to the <code>State</code> trait and add a new struct that
|
||
implements <code>State</code>, the <code>Published</code> state.</p>
|
||
<p>Similar to the way <code>request_review</code> on <code>PendingReview</code> works, if we call the
|
||
<code>approve</code> method on a <code>Draft</code>, it will have no effect because <code>approve</code> will
|
||
return <code>self</code>. When we call <code>approve</code> on <code>PendingReview</code>, it returns a new,
|
||
boxed instance of the <code>Published</code> struct. The <code>Published</code> struct implements the
|
||
<code>State</code> trait, and for both the <code>request_review</code> method and the <code>approve</code>
|
||
method, it returns itself because the post should stay in the <code>Published</code> state
|
||
in those cases.</p>
|
||
<p>Now we need to update the <code>content</code> method on <code>Post</code>. We want the value
|
||
returned from <code>content</code> to depend on the current state of the <code>Post</code>, so we’re
|
||
going to have the <code>Post</code> delegate to a <code>content</code> method defined on its <code>state</code>,
|
||
as shown in Listing 18-17.</p>
|
||
<figure class="listing" id="listing-18-17">
|
||
<span class="file-name">Filename: src/lib.rs</span>
|
||
<pre><code class="language-rust ignore does_not_compile"><span class="boring">pub struct Post {
|
||
</span><span class="boring"> state: Option<Box<dyn State>>,
|
||
</span><span class="boring"> content: String,
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span>impl Post {
|
||
// --snip--
|
||
<span class="boring"> pub fn new() -> Post {
|
||
</span><span class="boring"> Post {
|
||
</span><span class="boring"> state: Some(Box::new(Draft {})),
|
||
</span><span class="boring"> content: String::new(),
|
||
</span><span class="boring"> }
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> pub fn add_text(&mut self, text: &str) {
|
||
</span><span class="boring"> self.content.push_str(text);
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span> pub fn content(&self) -> &str {
|
||
self.state.as_ref().unwrap().content(self)
|
||
}
|
||
// --snip--
|
||
<span class="boring">
|
||
</span><span class="boring"> pub fn request_review(&mut self) {
|
||
</span><span class="boring"> if let Some(s) = self.state.take() {
|
||
</span><span class="boring"> self.state = Some(s.request_review())
|
||
</span><span class="boring"> }
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> pub fn approve(&mut self) {
|
||
</span><span class="boring"> if let Some(s) = self.state.take() {
|
||
</span><span class="boring"> self.state = Some(s.approve())
|
||
</span><span class="boring"> }
|
||
</span><span class="boring"> }
|
||
</span>}
|
||
<span class="boring">
|
||
</span><span class="boring">trait State {
|
||
</span><span class="boring"> fn request_review(self: Box<Self>) -> Box<dyn State>;
|
||
</span><span class="boring"> fn approve(self: Box<Self>) -> Box<dyn State>;
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span><span class="boring">struct Draft {}
|
||
</span><span class="boring">
|
||
</span><span class="boring">impl State for Draft {
|
||
</span><span class="boring"> fn request_review(self: Box<Self>) -> Box<dyn State> {
|
||
</span><span class="boring"> Box::new(PendingReview {})
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> fn approve(self: Box<Self>) -> Box<dyn State> {
|
||
</span><span class="boring"> self
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span><span class="boring">struct PendingReview {}
|
||
</span><span class="boring">
|
||
</span><span class="boring">impl State for PendingReview {
|
||
</span><span class="boring"> fn request_review(self: Box<Self>) -> Box<dyn State> {
|
||
</span><span class="boring"> self
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> fn approve(self: Box<Self>) -> Box<dyn State> {
|
||
</span><span class="boring"> Box::new(Published {})
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span><span class="boring">struct Published {}
|
||
</span><span class="boring">
|
||
</span><span class="boring">impl State for Published {
|
||
</span><span class="boring"> fn request_review(self: Box<Self>) -> Box<dyn State> {
|
||
</span><span class="boring"> self
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> fn approve(self: Box<Self>) -> Box<dyn State> {
|
||
</span><span class="boring"> self
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">}</span></code></pre>
|
||
<figcaption><a href="#listing-18-17">Listing 18-17</a>: Updating the <code>content</code> method on <code>Post</code> to delegate to a <code>content</code> method on <code>State</code></figcaption>
|
||
</figure>
|
||
<p>Because the goal is to keep all of these rules inside the structs that
|
||
implement <code>State</code>, we call a <code>content</code> method on the value in <code>state</code> and pass
|
||
the post instance (that is, <code>self</code>) as an argument. Then, we return the value
|
||
that’s returned from using the <code>content</code> method on the <code>state</code> value.</p>
|
||
<p>We call the <code>as_ref</code> method on the <code>Option</code> because we want a reference to the
|
||
value inside the <code>Option</code> rather than ownership of the value. Because <code>state</code> is
|
||
an <code>Option<Box<dyn State>></code>, when we call <code>as_ref</code>, an <code>Option<&Box<dyn State>></code> is returned. If we didn’t call <code>as_ref</code>, we would get an error because
|
||
we can’t move <code>state</code> out of the borrowed <code>&self</code> of the function parameter.</p>
|
||
<p>We then call the <code>unwrap</code> method, which we know will never panic because we
|
||
know the methods on <code>Post</code> ensure that <code>state</code> will always contain a <code>Some</code>
|
||
value when those methods are done. This is one of the cases we talked about in
|
||
the <a href="../ch09/ch09-03-to-panic-or-not-to-panic.html#cases-in-which-you-have-more-information-than-the-compiler">“When You Have More Information Than the
|
||
Compiler”</a><!-- ignore --> section of Chapter 9 when we
|
||
know that a <code>None</code> value is never possible, even though the compiler isn’t able
|
||
to understand that.</p>
|
||
<p>At this point, when we call <code>content</code> on the <code>&Box<dyn State></code>, deref coercion
|
||
will take effect on the <code>&</code> and the <code>Box</code> so that the <code>content</code> method will
|
||
ultimately be called on the type that implements the <code>State</code> trait. That means
|
||
we need to add <code>content</code> to the <code>State</code> trait definition, and that is where
|
||
we’ll put the logic for what content to return depending on which state we
|
||
have, as shown in Listing 18-18.</p>
|
||
<figure class="listing" id="listing-18-18">
|
||
<span class="file-name">Filename: src/lib.rs</span>
|
||
<pre><code class="language-rust noplayground"><span class="boring">pub struct Post {
|
||
</span><span class="boring"> state: Option<Box<dyn State>>,
|
||
</span><span class="boring"> content: String,
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span><span class="boring">impl Post {
|
||
</span><span class="boring"> pub fn new() -> Post {
|
||
</span><span class="boring"> Post {
|
||
</span><span class="boring"> state: Some(Box::new(Draft {})),
|
||
</span><span class="boring"> content: String::new(),
|
||
</span><span class="boring"> }
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> pub fn add_text(&mut self, text: &str) {
|
||
</span><span class="boring"> self.content.push_str(text);
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> pub fn content(&self) -> &str {
|
||
</span><span class="boring"> self.state.as_ref().unwrap().content(self)
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> pub fn request_review(&mut self) {
|
||
</span><span class="boring"> if let Some(s) = self.state.take() {
|
||
</span><span class="boring"> self.state = Some(s.request_review())
|
||
</span><span class="boring"> }
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> pub fn approve(&mut self) {
|
||
</span><span class="boring"> if let Some(s) = self.state.take() {
|
||
</span><span class="boring"> self.state = Some(s.approve())
|
||
</span><span class="boring"> }
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span>trait State {
|
||
// --snip--
|
||
<span class="boring"> fn request_review(self: Box<Self>) -> Box<dyn State>;
|
||
</span><span class="boring"> fn approve(self: Box<Self>) -> Box<dyn State>;
|
||
</span><span class="boring">
|
||
</span> fn content<'a>(&self, post: &'a Post) -> &'a str {
|
||
""
|
||
}
|
||
}
|
||
|
||
// --snip--
|
||
<span class="boring">
|
||
</span><span class="boring">struct Draft {}
|
||
</span><span class="boring">
|
||
</span><span class="boring">impl State for Draft {
|
||
</span><span class="boring"> fn request_review(self: Box<Self>) -> Box<dyn State> {
|
||
</span><span class="boring"> Box::new(PendingReview {})
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> fn approve(self: Box<Self>) -> Box<dyn State> {
|
||
</span><span class="boring"> self
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span><span class="boring">struct PendingReview {}
|
||
</span><span class="boring">
|
||
</span><span class="boring">impl State for PendingReview {
|
||
</span><span class="boring"> fn request_review(self: Box<Self>) -> Box<dyn State> {
|
||
</span><span class="boring"> self
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> fn approve(self: Box<Self>) -> Box<dyn State> {
|
||
</span><span class="boring"> Box::new(Published {})
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span>struct Published {}
|
||
|
||
impl State for Published {
|
||
// --snip--
|
||
<span class="boring"> fn request_review(self: Box<Self>) -> Box<dyn State> {
|
||
</span><span class="boring"> self
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> fn approve(self: Box<Self>) -> Box<dyn State> {
|
||
</span><span class="boring"> self
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span> fn content<'a>(&self, post: &'a Post) -> &'a str {
|
||
&post.content
|
||
}
|
||
}</code></pre>
|
||
<figcaption><a href="#listing-18-18">Listing 18-18</a>: Adding the <code>content</code> method to the <code>State</code> trait</figcaption>
|
||
</figure>
|
||
<p>We add a default implementation for the <code>content</code> method that returns an empty
|
||
string slice. That means we don’t need to implement <code>content</code> on the <code>Draft</code>
|
||
and <code>PendingReview</code> structs. The <code>Published</code> struct will override the <code>content</code>
|
||
method and return the value in <code>post.content</code>. While convenient, having the
|
||
<code>content</code> method on <code>State</code> determine the content of the <code>Post</code> is blurring
|
||
the lines between the responsibility of <code>State</code> and the responsibility of
|
||
<code>Post</code>.</p>
|
||
<p>Note that we need lifetime annotations on this method, as we discussed in
|
||
Chapter 10. We’re taking a reference to a <code>post</code> as an argument and returning a
|
||
reference to part of that <code>post</code>, so the lifetime of the returned reference is
|
||
related to the lifetime of the <code>post</code> argument.</p>
|
||
<p>And we’re done—all of Listing 18-11 now works! We’ve implemented the state
|
||
pattern with the rules of the blog post workflow. The logic related to the
|
||
rules lives in the state objects rather than being scattered throughout <code>Post</code>.</p>
|
||
<section class="note" aria-role="note">
|
||
<h3 id="why-not-an-enum"><a class="header" href="#why-not-an-enum">Why Not An Enum?</a></h3>
|
||
<p>You may have been wondering why we didn’t use an enum with the different
|
||
possible post states as variants. That’s certainly a possible solution; try it
|
||
and compare the end results to see which you prefer! One disadvantage of using
|
||
an enum is that every place that checks the value of the enum will need a
|
||
<code>match</code> expression or similar to handle every possible variant. This could get
|
||
more repetitive than this trait object solution.</p>
|
||
</section>
|
||
<!-- Old headings. Do not remove or links may break. -->
|
||
<p><a id="trade-offs-of-the-state-pattern"></a></p>
|
||
<h4 id="evaluating-the-state-pattern"><a class="header" href="#evaluating-the-state-pattern">Evaluating the State Pattern</a></h4>
|
||
<p>We’ve shown that Rust is capable of implementing the object-oriented state
|
||
pattern to encapsulate the different kinds of behavior a post should have in
|
||
each state. The methods on <code>Post</code> know nothing about the various behaviors.
|
||
Because of the way we organized the code, we have to look in only one place to
|
||
know the different ways a published post can behave: the implementation of the
|
||
<code>State</code> trait on the <code>Published</code> struct.</p>
|
||
<p>If we were to create an alternative implementation that didn’t use the state
|
||
pattern, we might instead use <code>match</code> expressions in the methods on <code>Post</code> or
|
||
even in the <code>main</code> code that checks the state of the post and changes behavior
|
||
in those places. That would mean we would have to look in several places to
|
||
understand all the implications of a post being in the published state.</p>
|
||
<p>With the state pattern, the <code>Post</code> methods and the places we use <code>Post</code> don’t
|
||
need <code>match</code> expressions, and to add a new state, we would only need to add a
|
||
new struct and implement the trait methods on that one struct in one location.</p>
|
||
<p>The implementation using the state pattern is easy to extend to add more
|
||
functionality. To see the simplicity of maintaining code that uses the state
|
||
pattern, try a few of these suggestions:</p>
|
||
<ul>
|
||
<li>Add a <code>reject</code> method that changes the post’s state from <code>PendingReview</code> back
|
||
to <code>Draft</code>.</li>
|
||
<li>Require two calls to <code>approve</code> before the state can be changed to <code>Published</code>.</li>
|
||
<li>Allow users to add text content only when a post is in the <code>Draft</code> state.
|
||
Hint: have the state object responsible for what might change about the
|
||
content but not responsible for modifying the <code>Post</code>.</li>
|
||
</ul>
|
||
<p>One downside of the state pattern is that, because the states implement the
|
||
transitions between states, some of the states are coupled to each other. If we
|
||
add another state between <code>PendingReview</code> and <code>Published</code>, such as <code>Scheduled</code>,
|
||
we would have to change the code in <code>PendingReview</code> to transition to
|
||
<code>Scheduled</code> instead. It would be less work if <code>PendingReview</code> didn’t need to
|
||
change with the addition of a new state, but that would mean switching to
|
||
another design pattern.</p>
|
||
<p>Another downside is that we’ve duplicated some logic. To eliminate some of the
|
||
duplication, we might try to make default implementations for the
|
||
<code>request_review</code> and <code>approve</code> methods on the <code>State</code> trait that return <code>self</code>.
|
||
However, this wouldn’t work: When using <code>State</code> as a trait object, the trait
|
||
doesn’t know what the concrete <code>self</code> will be exactly, so the return type isn’t
|
||
known at compile time. (This is one of the dyn compatibility rules mentioned
|
||
earlier.)</p>
|
||
<p>Other duplication includes the similar implementations of the <code>request_review</code>
|
||
and <code>approve</code> methods on <code>Post</code>. Both methods use <code>Option::take</code> with the
|
||
<code>state</code> field of <code>Post</code>, and if <code>state</code> is <code>Some</code>, they delegate to the wrapped
|
||
value’s implementation of the same method and set the new value of the <code>state</code>
|
||
field to the result. If we had a lot of methods on <code>Post</code> that followed this
|
||
pattern, we might consider defining a macro to eliminate the repetition (see
|
||
the <a href="../ch20/ch20-05-macros.html#macros">“Macros”</a><!-- ignore --> section in Chapter 20).</p>
|
||
<p>By implementing the state pattern exactly as it’s defined for object-oriented
|
||
languages, we’re not taking as full advantage of Rust’s strengths as we could.
|
||
Let’s look at some changes we can make to the <code>blog</code> crate that can make
|
||
invalid states and transitions into compile-time errors.</p>
|
||
<h3 id="encoding-states-and-behavior-as-types"><a class="header" href="#encoding-states-and-behavior-as-types">Encoding States and Behavior as Types</a></h3>
|
||
<p>We’ll show you how to rethink the state pattern to get a different set of
|
||
trade-offs. Rather than encapsulating the states and transitions completely so
|
||
that outside code has no knowledge of them, we’ll encode the states into
|
||
different types. Consequently, Rust’s type-checking system will prevent
|
||
attempts to use draft posts where only published posts are allowed by issuing a
|
||
compiler error.</p>
|
||
<p>Let’s consider the first part of <code>main</code> in Listing 18-11:</p>
|
||
<figure class="listing">
|
||
<span class="file-name">Filename: src/main.rs</span>
|
||
<pre><code class="language-rust ignore"><span class="boring">use blog::Post;
|
||
</span><span class="boring">
|
||
</span>fn main() {
|
||
let mut post = Post::new();
|
||
|
||
post.add_text("I ate a salad for lunch today");
|
||
assert_eq!("", post.content());
|
||
<span class="boring">
|
||
</span><span class="boring"> post.request_review();
|
||
</span><span class="boring"> assert_eq!("", post.content());
|
||
</span><span class="boring">
|
||
</span><span class="boring"> post.approve();
|
||
</span><span class="boring"> assert_eq!("I ate a salad for lunch today", post.content());
|
||
</span>}</code></pre>
|
||
</figure>
|
||
<p>We still enable the creation of new posts in the draft state using <code>Post::new</code>
|
||
and the ability to add text to the post’s content. But instead of having a
|
||
<code>content</code> method on a draft post that returns an empty string, we’ll make it so
|
||
that draft posts don’t have the <code>content</code> method at all. That way, if we try to
|
||
get a draft post’s content, we’ll get a compiler error telling us the method
|
||
doesn’t exist. As a result, it will be impossible for us to accidentally
|
||
display draft post content in production because that code won’t even compile.
|
||
Listing 18-19 shows the definition of a <code>Post</code> struct and a <code>DraftPost</code> struct,
|
||
as well as methods on each.</p>
|
||
<figure class="listing" id="listing-18-19">
|
||
<span class="file-name">Filename: src/lib.rs</span>
|
||
<pre><code class="language-rust noplayground">pub struct Post {
|
||
content: String,
|
||
}
|
||
|
||
pub struct DraftPost {
|
||
content: String,
|
||
}
|
||
|
||
impl Post {
|
||
pub fn new() -> DraftPost {
|
||
DraftPost {
|
||
content: String::new(),
|
||
}
|
||
}
|
||
|
||
pub fn content(&self) -> &str {
|
||
&self.content
|
||
}
|
||
}
|
||
|
||
impl DraftPost {
|
||
pub fn add_text(&mut self, text: &str) {
|
||
self.content.push_str(text);
|
||
}
|
||
}</code></pre>
|
||
<figcaption><a href="#listing-18-19">Listing 18-19</a>: A <code>Post</code> with a <code>content</code> method and a <code>DraftPost</code> without a <code>content</code> method</figcaption>
|
||
</figure>
|
||
<p>Both the <code>Post</code> and <code>DraftPost</code> structs have a private <code>content</code> field that
|
||
stores the blog post text. The structs no longer have the <code>state</code> field because
|
||
we’re moving the encoding of the state to the types of the structs. The <code>Post</code>
|
||
struct will represent a published post, and it has a <code>content</code> method that
|
||
returns the <code>content</code>.</p>
|
||
<p>We still have a <code>Post::new</code> function, but instead of returning an instance of
|
||
<code>Post</code>, it returns an instance of <code>DraftPost</code>. Because <code>content</code> is private and
|
||
there aren’t any functions that return <code>Post</code>, it’s not possible to create an
|
||
instance of <code>Post</code> right now.</p>
|
||
<p>The <code>DraftPost</code> struct has an <code>add_text</code> method, so we can add text to
|
||
<code>content</code> as before, but note that <code>DraftPost</code> does not have a <code>content</code> method
|
||
defined! So now the program ensures that all posts start as draft posts, and
|
||
draft posts don’t have their content available for display. Any attempt to get
|
||
around these constraints will result in a compiler error.</p>
|
||
<!-- Old headings. Do not remove or links may break. -->
|
||
<p><a id="implementing-transitions-as-transformations-into-different-types"></a></p>
|
||
<p>So, how do we get a published post? We want to enforce the rule that a draft
|
||
post has to be reviewed and approved before it can be published. A post in the
|
||
pending review state should still not display any content. Let’s implement
|
||
these constraints by adding another struct, <code>PendingReviewPost</code>, defining the
|
||
<code>request_review</code> method on <code>DraftPost</code> to return a <code>PendingReviewPost</code> and
|
||
defining an <code>approve</code> method on <code>PendingReviewPost</code> to return a <code>Post</code>, as
|
||
shown in Listing 18-20.</p>
|
||
<figure class="listing" id="listing-18-20">
|
||
<span class="file-name">Filename: src/lib.rs</span>
|
||
<pre><code class="language-rust noplayground"><span class="boring">pub struct Post {
|
||
</span><span class="boring"> content: String,
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span><span class="boring">pub struct DraftPost {
|
||
</span><span class="boring"> content: String,
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span><span class="boring">impl Post {
|
||
</span><span class="boring"> pub fn new() -> DraftPost {
|
||
</span><span class="boring"> DraftPost {
|
||
</span><span class="boring"> content: String::new(),
|
||
</span><span class="boring"> }
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> pub fn content(&self) -> &str {
|
||
</span><span class="boring"> &self.content
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span>impl DraftPost {
|
||
// --snip--
|
||
<span class="boring"> pub fn add_text(&mut self, text: &str) {
|
||
</span><span class="boring"> self.content.push_str(text);
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span> pub fn request_review(self) -> PendingReviewPost {
|
||
PendingReviewPost {
|
||
content: self.content,
|
||
}
|
||
}
|
||
}
|
||
|
||
pub struct PendingReviewPost {
|
||
content: String,
|
||
}
|
||
|
||
impl PendingReviewPost {
|
||
pub fn approve(self) -> Post {
|
||
Post {
|
||
content: self.content,
|
||
}
|
||
}
|
||
}</code></pre>
|
||
<figcaption><a href="#listing-18-20">Listing 18-20</a>: A <code>PendingReviewPost</code> that gets created by calling <code>request_review</code> on <code>DraftPost</code> and an <code>approve</code> method that turns a <code>PendingReviewPost</code> into a published <code>Post</code></figcaption>
|
||
</figure>
|
||
<p>The <code>request_review</code> and <code>approve</code> methods take ownership of <code>self</code>, thus
|
||
consuming the <code>DraftPost</code> and <code>PendingReviewPost</code> instances and transforming
|
||
them into a <code>PendingReviewPost</code> and a published <code>Post</code>, respectively. This way,
|
||
we won’t have any lingering <code>DraftPost</code> instances after we’ve called
|
||
<code>request_review</code> on them, and so forth. The <code>PendingReviewPost</code> struct doesn’t
|
||
have a <code>content</code> method defined on it, so attempting to read its content
|
||
results in a compiler error, as with <code>DraftPost</code>. Because the only way to get a
|
||
published <code>Post</code> instance that does have a <code>content</code> method defined is to call
|
||
the <code>approve</code> method on a <code>PendingReviewPost</code>, and the only way to get a
|
||
<code>PendingReviewPost</code> is to call the <code>request_review</code> method on a <code>DraftPost</code>,
|
||
we’ve now encoded the blog post workflow into the type system.</p>
|
||
<p>But we also have to make some small changes to <code>main</code>. The <code>request_review</code> and
|
||
<code>approve</code> methods return new instances rather than modifying the struct they’re
|
||
called on, so we need to add more <code>let post =</code> shadowing assignments to save
|
||
the returned instances. We also can’t have the assertions about the draft and
|
||
pending review posts’ contents be empty strings, nor do we need them: We can’t
|
||
compile code that tries to use the content of posts in those states any longer.
|
||
The updated code in <code>main</code> is shown in Listing 18-21.</p>
|
||
<figure class="listing" id="listing-18-21">
|
||
<span class="file-name">Filename: src/main.rs</span>
|
||
<pre><code class="language-rust ignore">use blog::Post;
|
||
|
||
fn main() {
|
||
let mut post = Post::new();
|
||
|
||
post.add_text("I ate a salad for lunch today");
|
||
|
||
let post = post.request_review();
|
||
|
||
let post = post.approve();
|
||
|
||
assert_eq!("I ate a salad for lunch today", post.content());
|
||
}</code></pre>
|
||
<figcaption><a href="#listing-18-21">Listing 18-21</a>: Modifications to <code>main</code> to use the new implementation of the blog post workflow</figcaption>
|
||
</figure>
|
||
<p>The changes we needed to make to <code>main</code> to reassign <code>post</code> mean that this
|
||
implementation doesn’t quite follow the object-oriented state pattern anymore:
|
||
The transformations between the states are no longer encapsulated entirely
|
||
within the <code>Post</code> implementation. However, our gain is that invalid states are
|
||
now impossible because of the type system and the type checking that happens at
|
||
compile time! This ensures that certain bugs, such as display of the content of
|
||
an unpublished post, will be discovered before they make it to production.</p>
|
||
<p>Try the tasks suggested at the start of this section on the <code>blog</code> crate as it
|
||
is after Listing 18-21 to see what you think about the design of this version
|
||
of the code. Note that some of the tasks might be completed already in this
|
||
design.</p>
|
||
<p>We’ve seen that even though Rust is capable of implementing object-oriented
|
||
design patterns, other patterns, such as encoding state into the type system,
|
||
are also available in Rust. These patterns have different trade-offs. Although
|
||
you might be very familiar with object-oriented patterns, rethinking the
|
||
problem to take advantage of Rust’s features can provide benefits, such as
|
||
preventing some bugs at compile time. Object-oriented patterns won’t always be
|
||
the best solution in Rust due to certain features, like ownership, that
|
||
object-oriented languages don’t have.</p>
|
||
<h2 id="summary"><a class="header" href="#summary">Summary</a></h2>
|
||
<p>Regardless of whether you think Rust is an object-oriented language after
|
||
reading this chapter, you now know that you can use trait objects to get some
|
||
object-oriented features in Rust. Dynamic dispatch can give your code some
|
||
flexibility in exchange for a bit of runtime performance. You can use this
|
||
flexibility to implement object-oriented patterns that can help your code’s
|
||
maintainability. Rust also has other features, like ownership, that
|
||
object-oriented languages don’t have. An object-oriented pattern won’t always
|
||
be the best way to take advantage of Rust’s strengths, but it is an available
|
||
option.</p>
|
||
<p>Next, we’ll look at patterns, which are another of Rust’s features that enable
|
||
lots of flexibility. We’ve looked at them briefly throughout the book but
|
||
haven’t seen their full capability yet. Let’s go!</p>
|
||
</body>
|
||
</html>
|