Swiftの世界的カンファレンス，try! Swiftが3月2日～4日の3日間にわたり，渋谷のサイバーエージェントのオフィスにて開催されました。

本イベントの興味深いセッションをいくつか，日ごとにレポートしています。1日目のレポートに続き，2日目の模様をレポートします。

Ayaka Nonakaさん「実践的 "Boundaries"」

venmoでiOSのリードをしているAyaka Nonakaさん（@ayanogagon）は，Boundariesで得た知見を元に実践的なSwiftのコードに落としこむテクニックを発表しました。

Gary BernhardtさんのBOUNDARIESという講演を聞いた時に「Functional Core」と「Imperative Shell」をどう活用できるか悩んでいたそうです。悩んだ結果，最初は理論を感覚で捉えて，実装時に「使えるのでは？」と思った時に使えば良いと考えるようになったそうです。

IMMUTABLE CORE NETWORK-Y SHELL

Functional Coreを不変なコア，Imperative Shellをネットワーク環境による表面として例示しました。

最初に与えられた値によって表示内容が確定する画面の場合はFunctional Coreとして振る舞うことができます。上記とはまた別でネットワークを用いて後から詳細な情報を取得するような流動的な画面はImperative Shellとして振る舞うことができるとのことでした。

境界（Boundary）を見つける

実装設計をする上で，コードのどの部分が不変なもので「堅実なパターン」に適しているか把握し，そして同じようにどの部分がネットワークコードのように「流動的なパターン」に適しているかを把握するのが大切だと言います。「⁠堅実なパターン」と「流動的なパターン」のバランスをとり，境界（Boundary）を見つけることで，安全で将来性のあるコードが書けると述べていました。

Adam Bellさん「プロトタイピングの魔法」

facebookから提供されているアニメーションエンジンpopのメンテナンスをしているAdam Bellさん（@b3ll）は，アニメーションのプロトタイピングについてセッションを行いました。

振り返り

iOS 7以前のUIがスキューモーフィズムだった頃のアニメーションとiOS 7以降のフラットでシンプルなUIのアニメーションを振り返りました。スキューモーフィズムが実世界の物に似せるようなアニメーションをすることに対し，iOS 7以降のアニメーションはシンプルなものになっていました。ただアニメーションが不要になったというわけではなく，アプリケーション自体を楽しくさせるためにアニメーションは重要な要素であると指摘しました。アニメーションは何が起きるのかを見せるものであって，必ず目的と意図が必要とのことです。

アニメーションを入れない選択肢をしない

また，アプリケーションの動作が遅くなるからといってアニメーションを入れないのではなく，適切な方法で実装すべきとのことでした。CoreAnimationはフレームを落とさないように設計されており，CARenderServerで高い優先度で処理されるため，最適化をしていないコードで使わない限り遅くなることは無いと説明しました。

Xcodeのplaygroundでプロトタイピング

アニメーション作成のプロトタイピングツールとしてXcodeのPlaygroundを使った方法を実践していきました。次期バージョンよりジェスチャも使えるようになるため，タップした際のアニメーションも結果が見やすくなっていました。

XcodeをSwiftで簡単にプロトタイピングができるようになったので，自分の限界を引き上げるようなコードに挑戦してくださいと述べていました。

Matthew Gillinghamさん「プロトコルエクステンション：歴史について」

Tokyo iOS Meetupの主催をしているMatthew Gillinghamさん（@gillygize）は，プロトコルエクステンションに至るまでの言語の歴史を紹介しました。

継承と抽象の問題

まずはオブジェクト指向のなかで，継承という概念が生まれ，やがて抽象クラスの概念ができました。ただし，シングルインヘリタンスはクロスカッティング問題が存在します。構造が違うサブクラスが2つ以上存在する場合，片方のサブクラスからサブクラスを作成した場合，もう片方のサブクラスの実装コードの共有ができなくなってしまいます。

また，同じインターフェースを持つ親を複数継承したときインターフェースが衝突してしまう問題があります。この問題はダイヤモンド継承問題と言われています。

プロトコルの誕生

そこでメソッドの名前で具体的な実装情報は持っていないprotocolという概念が生まれました。protocolはメソッド名のみで実装コードを持たないため，実装コード同士が衝突してしまうダイヤモンド継承問題を解決しました。

プロトコルエクステンションの誕生

protocol extensionが生まれ，継承関係のないクラス同士でもクリーンな形で実装コードの共有ができるようになりました。

ただしMatthewさんは，protocol extensionはパワフルですが，protocol extension同士が衝突した際の問題など，別の複雑さが導入されていることに注意しました。