Matthew Gillingham
Tonchidot, GREE, Mediweb、Eventacularといった日本企業で7年間iOS開発をしています。また、5年以上もAppleのプラットフォーム上で開発している人達の国際的なコミュニティであるTokyo iOS Meetupのオーガナイザーをしています。
Swift 2.0のプロトコルエクステンションに至るまでの、プログラミング言語におけるコードの再利用と共通化の歴史をお話しします。
レコードクラスというコンセプト、サブクラス、Null参照を作りました。 あとで何十億ドルもの過ちだと言っています。
しかしこれはオプショナルではありません
有料道路の料金徴収をシミュレーションしました
いろんな車がありサブクラスが必要になりいろいろアクションする。
車のタイプで動きが違う。
そういったコンセプトとして継承を作った
アランKも共感
継承が他の言語に大きな影響、抽象クラスも生まれた
これが理想と考えられていた
抽象クラスを作り、具象クラスを実装、コードシェアリングをすると。
しかし必ずしもこれが向いているとは限らない、グループ化したりして、一箇所変更すると抽象化したものとは変わってくる。具体化すると違うものになってしまうことがある。そこでもう少し自由になろうと
アランKはオブジェクト指向は難しいと言っている
シングル継承は価値はない
クロスカッティング問題がある
たとえば。。。
スクロールビュー上で何か実装したらUITableViewにも対応してもらいたい。
でも構造上実は簡単には共有できない。シングル継承の問題。クロスカッティング。
複数から継承していく、しかしそれにも問題がある。ダイヤモンド問題。
同じインターフェースを持つかもしれない親を複数継承したいと、問題になる。
この解決のため、
Flavor：複数のものを混ぜてクラスに入れていく
60-70年代のオブジェクト指向が限界を感じられた
かいけつしようとして更に新しい問題、それがダイヤモンド問題
通信業界で使っていて問題に気づいた。Smaltalkに着目して、C拡張で解決しようとした
新しいエンティティを追加した時、For loopでアップデートする、大きなシステムでやると、いろんなおところで変更しなくてはいけないのを解決したいと思った。
SmallTalkの中にオブジェクトにPrintめそっどをもたせ、新しい物を作るときはPrintだけを変えてForLoopを買える必要はない、ダイナミックディスパッチに着目した。
しかし間違ったオブジェクトを放り込んでエラーになることがある
解決しようとしてまた新たな問題が生まれる。
JobsがNextStepでProtocolを導入
誰が発明したのか明らかではないが、プロトコルは実質的にメソッドの名前で具体的な実装情報は入っていない。
Arrayに入るものはプロトコルに準拠している
準拠していなければコンパイラエラーが出る
Printメソッドを持っているか確認できる
もう一つ興味深い特性としてダイヤモンド問題がない。メソッド名のみのため
2015年にはSwiftはProtocol指向言語と言っています。Extensionも有ります。
メソッド名だけでなくなった。
私はAutolayoutを使っています。トップアンカーボトムアンカーが新たに導入、レイアウトガイドも出来ました。同じようなプロパティだが継承関係がありません。
Extensionでこういうことが出来る
その結果クリーンな形でコードを共有し簡単に効果を出せます。
こういう時はどうでしょう
ここでは問題はありません。Aが実装を提供しているからBは満足している。
Extensionが両方あったらコンパイラエラー
そこで独自実装するか？
こういうのはどうでしょうか
コリジョンするとデバッグしにくい。
申し上げたいのは、プロトコルエクステンションはパワフルだが、別の複雑さを導入してしまう
名前は慎重につける必要がある。名前の衝突の可能性が増える。
解決は、過去の歴史のように、ベストプラクティスの模索をやっていく必要があるでしょう。
一つの解決策として考えられるのはプロトコルを使ってオブジェクトを定義しているから、プロトコルとしてどのメソッドで使うのかキャスティングするということが出来ませんか？同じ実装をもったプロトコル、どちらも実装を持つエクステンションがある。オブジェクトとしてキャスティングしてプロトコルとして呼び出せるか
可能だ。ただ複雑なところが他にもあって、デフォルト実装のあるプロトコルがあって実装があるクラスがあってキャストすると。。。予期しない挙動が起きることも考えられます。
MixInとどう違うのか
幅の広い問題だ。メソッドの実装である場合もあればSwiftの場合はプロパティを、実際には提供しない、提供する場合もあるが。非常に幅広いトピックなので言語ごとに戦略が有り異なるタイプが有る。 違いとしては例えばProtocolExtensionは度のクラスに定義されるかを文法で示すことが出来たりする。多くの言語がいろいろな形でやっていて非常に興味深いといえると思います。
protocol extension 導入によって多重継承問題が再燃してしまって解決方法はまだない、という話だった。うーん・・・ #tryswiftconf
— 宇佐見 公輔 (@usamik26) 2016年3月3日
この心配は結構気になっている。でもやっぱり有効な解決策はないのか https://t.co/GhTVfnzrwu #tryswiftconf
— Motoki Narita (@mo_to_44) 2016年3月3日
protocol extensionでデフォルト実装を持てるようになったことで、ダイヤモンド継承の問題が再燃してくるし、それはまだ解決していない #tryswiftconf
— Hirohito Kato ⌘ (@hkato193) 2016年3月3日
「コードの再利用と共通化の歴史を巡る "プロトコルエクステンション"という解決法 #tryswiftconf」をトゥギャりました。 https://t.co/C55bBoMxaf
— トゥギャッター開発まとめ (@tg__dev) 2016年3月3日
気に入った記事は はてなブックマーク
はてなブックマークアプリiOS開発チームから来ました！ はてなブックマークにはSwift特集があります！ 良い記事を見逃さないように、ご利用ください！ http://b.hatena.ne.jp/hotentry/it/Swift
そして良いまとめ記事があったらはてなブックマークでブックマークしましょう！ try! Swift の記事で盛り上がると嬉しいです！
