ようこそ!浜村拓夫の世界へ

    ブログ内検索

    最近の記事

    ブックマーク数の多い記事

    Blog Translation

    Powered By FC2ブログ

    Powered By FC2ブログ
    ブログやるならFC2ブログ


    FC2ブログ LOGIN

    with Ajax Amazon

    プロトコル指向プログラミング

    このエントリーを含むはてなブックマーク はてなブックマーク - プロトコル指向プログラミング あとで読む
    Swiftのプログラミング・パラダイムで、「プロトコル指向プログラミング」という考え方が提唱されていました。
    要は、Java(オブジェクト指向プログラミング)のインターフェースに相当する機能を、Appleで手を加えてより高機能にした仕組みを「プロトコル」と呼んでいました。

    Swiftで提供されている「プロトコル」という機能を活用すると、いろいろ便利になると宣伝されています。
    AndroidもSwiftを採用してくれたら、スマホアプリは全部SwiftでOKでしょうか!?

    ASCII.jp:グーグルの「Swift」採用はあり得るのか、アプリ開発言語を考える|Windows情報局ななふぉ出張所


    ●マルチパラダイムのSwift

    文化を調和させる: 関数型プログラミング、プロトコル志向プログラミング、オブジェクト指向プログラミングの優れたテクニックを取り入れる, with Daniel Steinberg - Realm is a mobile database: a replacement for SQLite & Core Data

    Swiftを始めるにあたって、たいていの場合は既存のObjective-Cのコードを単に書き換えるだけということが多いでしょう。これからお見せするのは、みなさんご存知のプログラミングのパラダイムである、オブジェクト志向プログラミング、関数型プログラミング、プロトコル志向プログラミングの手法をすべてミックスした、よりSwiftらしいコードを書くためのテクニックです。



    ・オブジェクト指向プログラミング
    ・プロトコル指向プログラミング
    それぞれ別のものとして、列挙しているんですね!


    ●インターフェースとプロトコルの違い

    Tumbling Dice — [Swift]Appleの新言語「Swift」のリファレンスを読む(16) - Protocols

    ■ Protocols(プロトコル)

    俗に言うインターフェースと言うやつです。Objective-Cでもその手の機構はプロトコルと呼ばれていたみたいなので、そのまま引き継いだのでしょう。

    普段はJavaとかC#とかをやってるので、どうしてもこの手のものを使用することに対して「実装する」(implement)って言ってしまうんですが、Swift(Objective-C)では「適合する」(conform to、adapt to)と呼んでいるそうです。個人的には非常に違和感があるんですが、仕方ないのでこの章ではそう呼びます。



    Swift におけるオプショナルなメソッドについて真面目に考える – NET BIZ DIV. TECH BLOG

    Objective-C におけるプロトコルを説明する際によく引き合いに出されるのが Java などのインターフェース(Interface)です。違いは、 Java などのインターフェースは実装(implements)するものであるのに対して、プロトコルは 採用(adopt)するものであることです。

    具体的にいうと、プロトコルでは実装が必須であるメソッドと必須でないメソッドを定義できます。
    したがって、Objective-C では、プロトコルを採用しているからといって 必ず is-a 関係になるわけではないため、動的にメソッドの実装の有無を判定する必要性が生じてしまいます。



    ・Javaのインターフェースに相当する機能は、Objective-Cのときからプロトコルと呼ばれていた。
    ・Swiftでも、Objective-Cの呼称を継承して、インターフェースのことをプロトコルと呼んでいる。

    ・インターフェースは、実装が必須。
    ・プロトコルは、実装が必須の場合と、必須ではない場合がある。
    =インターフェースよりも、プロトコルの方が、実現できる処理が多い。

    Swiftにおけるプロトコル指向プログラミング

    OOPで知られているように、クラスは以下を提供するのに使われる。

    ・カプセル化
    ・アクセス制御
    ・抽象化
    ・名前空間
    ・表現力
    ・拡張性

    実のところ、これらはすべて型の特性であり、クラスは型を実装する一つの方法にすぎないとAbrahams氏は言う。だが、クラスはプログラマに多大な犠牲を強い、次のようなことが起こるおそれがある。

    ・暗黙の共有。
    たとえば、2つのオブジェクトが第3のオブジェクトを参照している場合、2つのオブジェクトは互いにそのことを知らずに、第3のオブジェクトを変更できてしまう。共有を回避するため、参照するオブジェクトを複製すると、今度は効率がわるくなる。ロックを使って競合を避けるという方法もある。だが、これはさらに効率をわるくし、デッドロックにつながるおそれもある。コードはさらに複雑になる。これはバグがさらに増えることを意味する。

    ・継承問題。
    多くのオブジェクト指向言語では、スーパークラスを一つしか持つことができず、初期の段階で選ばなくてはならない。スーパークラスをあとから変更するのは、極めて困難だ。またスーパークラスは派生クラスにストアドプロパティを強制する。これは初期化の処理と、スーパークラスが求める普遍性を壊さないようにするのを複雑にする。さらに通常は、オーバーライドできるもの、そのやり方、いつすべきでないかに制約がある。こうした制約は通常、ドキュメントに残される。

    ・型関係の喪失。
    これはインターフェイスと実装の合体によるものだ。通常、実装できないベースクラスのメソッドに現れ、派生クラスのメソッド実装において、派生クラスにダウンキャストする必要がある。これは次のコードを使って説明された。



    プロトコル指向プログラミングは、以下の点で、より優れた抽象化の仕組みだという。

    ・バリュー型(クラスを除く)
    ・静的な型関係(動的ディスパッチを除く)
    ・レトロプロアクティブなモデリング
    ・モデルにデータを強制しない
    ・初期化の負担がない
    ・何が実装されなくてはならないかが明確

    大きなクラスをリファクタリングするときには、プロトコルと構造体を使って取り除くと、もっと改善できるだろう。



    Swiftには、関数型の参照透過性を活かして、テストを簡便に済ませる路線を追及して欲しいような気もしますが、まあそれはAppleが考えるべきことですね。
    土方プログラマーは、Apple様から支給されたSwiftを、ただ使う立場でしかないので、ウダウダ言っても仕方ないでしょう。
    まあ、でもSwiftがオープンソース化されたから、何らかのコミットは可能かな?

    詳解 Swift 改訂版
    荻原 剛志
    SBクリエイティブ
    2015-12-25
    ¥ 3,456

    関連記事

    コメント

    コメントの投稿


    管理者にだけ表示を許可する

    トラックバック

    トラックバックURL:
    http://hamamuratakuo.blog61.fc2.com/tb.php/1361-33bcbb78

    FC2Ad