The first code example I found in the book preview — the Prototype pattern, pp.4-5 — is incorrect:
class AbstractCard {
func clone() -> AbstractCard {
return AbstractCard(name:
self.name, /* etc. */)
}
}
class Card {
override init( name: String, /* etc. */ ) { … }
}
Calling clone on a Card instance will return an AbstractCard, not a Card. In fact if you look closely at the screenshot of the playground on p.6, the results column shows that the result of `raidLeader.clone()` is an AbstractCard, while the original `raidLeader` is a Card. Yes, you’ve set it up so the resulting object has the same properties as the original, but it’s the wrong class, so it’s probably not going to have the correct behavior. To work properly, the Clone pattern has to return an object identical in behavior to the original.
The proper implementation in Swift would be to make AbstractCard.clone() an abstract method, and override it in Card to return `Card(name:
self.name, /* etc. */)`.
It also seems a pretty major omission to not talk about the existing standard implementation of the Prototype pattern via Foundation's NSCopying protocol and its -copy method. Anyone implementing Swift classes that inherit from NSObject should use that instead of rolling their own.
(Also, why is the subtitle “Build robust and scalable iOS and Mac OS X game applications”? None of these patterns are specific to games, and using patterns is only a tiny part of what you need to know to write a game.)
—Jens