Swift 2.0 Design Patterns - a step by step simple approach

[Julien LANGE]

• Learn to use and implement the 23 Gang of Four design patterns using Swift 2
• Design and architect your code for Swift application development
• Understand the role, generic UML design, and participants in the class diagram of the pattern by implementing them in a step-by-step approach

This book will help any developers to become different compared to other developers by allowing them at whic problem a design pattern answer, and will help him to build robust and scalable iOS or MacOSX applications and games.

I am able to answer to your messages too if you have any queries about the book.

http://www.amazon.com/Swift-Design-Patterns-Julien-Lange/dp/1785887610/

[Jens Alfke]

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

[Julien LANGE]

Hello Jens,

thanks a lot for your email.

Indeed your are right with that pattern, it was one of the first written chapters and seems that reviewer doesn’t saw that « mistake » too. 

About the NSCopying protocol : when i started to write this book  i focused only to implement the GOF patterns from scratch. So, Note that i had a limitation to about 180 pages to write for this book at the start of the project. So i couldn’t add too more informations when i started it.

Chapters after chapters, and after receiving first reviews from reviewers, i decided to add some interesting informations (like double dispatch usage, grand central dispatch …) .

Today, i think that adding such informations would be something interesting for iOS developers already having some swift knowledge.

Last, I will contact Packt about it to see if we can make an update about this chapter in a future release of the book. 

Thanks again.

Comments like yours are really appreciated !

Sincerely.

Julien