今回は、出だしは少し辛口。

MacOS時代、クラスライブラリMacAppを使用したプログラミングの手法として、オブジェクト・プログラミングというのがあった。これは、利用側が、必ずしもオブジェクト指向プログラミングをする必要がない。オブジェクト指向で実装されたライブラリを利用すればいいということだったと思う。

この考えは、NeXTstepでもあったと思っていて、継承以外のクラスを拡張する方法としてデリゲートが用意されていたり、InterfaceBuilderはクラスでなく、インスタンスを生成するところなどがそうではないだろうか？

自分はたいした職歴でないが、過去を思い出すと、継承を多用したプロジェクトは、必ず、スパゲッティになっていた。何が問題なのかなとボンヤリと思うと、継承をコードの共通化として利用し、オブジェクトとしての構成がよくなかったのではないか？では、そこを頑張ればいいのかというと頑張ると変な方向に行ってしまうような。

なかなか、この考えに考え抜いたスパゲティを生産される方は、その主張がパッと聞くと正論のように思われ、止めることはできず。逆に止めようとすると、論争になり、ますます、泥沼にはまっていたよな〜。

恐ろしいのは、この設計論争は、何もモノを生み出さない。趣味ですね。

Swiftでclass出なくstructを。継承でなくプロトコルを勧めているのも、多くの方々が、このスパゲティ・クラスに疲れ果ててしまったからかな思う。

イカンイカン。脱線しているので本題に戻る。

今回取り上げるのはWWDC2015のセッション『Protocol-Oriented Programming in Swift』。

課題を3つ挙げている。

Implicit Sharing
Inheritance All Up In Your Business
Lost Type Relationships

一つ目は、リファレンス型のことを言っているようで、値を変えると、他で所有しているところで驚くという内容だ。ただ、これは、以前も説明した通りモジュール化の問題で、Model（Dataコントローラ）を用意するとか、必要な複製は行うとかすれば問題ないと考えている。

二つ目は、継承の問題で、パッと思いついたのは、親でreadonlyにしたが、一部の子でwriteしたくなり、そのためにそれ専用のメソッドを用意したり、逃げで苦労するということか。継承しすぎ、Baseクラスやめたら、ですね。

最後は型の問題で、親子で方がうまくいかず、他の子のことを考慮したり、親で子を考慮したりということか。

ということで、推奨されたのが以下の7つ。

Supports value types (and classes)
Supports static type releationships (and dynamic dispatch)
Non-monolithic
Supports retroactive modeling
Doesn't impose instance data on models
Doesn't impose initialization burdens on models
Makes clear what to implement

詳細は割愛するが、それでプロトコル指向プログラミングということだが、何とか指向というと、スパゲティの悪夢が蘇って腰が引けてしまうが、まずは、自称オブジェクト指向プログラミングを制限するというのは、いいかも。

これで、悲劇が繰り返さないことを願う。

ソースコード
GitHubからどうぞ。

https://github.com/murakami/workbook/tree/master/ios/Hand - GitHub

関連情報
文化を調和させる

【Cocoa練習帳】
http://www.bitz.co.jp/weblog/

http://ameblo.jp/bitz/（ミラー・サイト）