diff --git a/src/ch18-03-oo-design-patterns.md b/src/ch18-03-oo-design-patterns.md index 34fea1f017..a689a6ab5d 100644 --- a/src/ch18-03-oo-design-patterns.md +++ b/src/ch18-03-oo-design-patterns.md @@ -359,11 +359,12 @@ known at compile time. (This is one of the dyn compatibility rules mentioned earlier.) Other duplication includes the similar implementations of the `request_review` -and `approve` methods on `Post`. Both methods delegate to the implementation of -the same method on the value in the `state` field of `Option` and set the new -value of the `state` field to the result. If we had a lot of methods on `Post` -that followed this pattern, we might consider defining a macro to eliminate the -repetition (see [“Macros”][macros] in Chapter 20). +and `approve` methods on `Post`. Both methods use `Option::take` with the +`state` field of `Post`, and if `state` is `Some`, they delegate to the wrapped +value’s implementation of the same method and set the new value of the `state` +field to the result. If we had a lot of methods on `Post` that followed this +pattern, we might consider defining a macro to eliminate the repetition (see +[“Macros”][macros] in Chapter 20). 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.