動的束縛（ダイナミックバインディング）とは？

Question

最近オブジェクト指向についていろいろ調べ始め、
三大要素とは別に動的束縛もメリットの一つだと目にしました。

ただ、動的束縛で検索をしてもあまりピンとくる説明がなされてるページが見当たりません。

一年前の記事ですが多少触れていることがあったのでURLを張っておきます。

http://qiita.com/cedretaber/items/45ad0580ab5eaa64c7ab

このサイトを見る限りだと、自分なりの解釈で動的束縛について記載していますが、一番最後の結び部分で、誰か動的束縛教えてくれメンスと言ってらっしゃいます。

結局のところ、動的束縛のメリット、デメリット。有用な活用法がわからないままで終わってしまいました。

自分なりの解釈ではメソッドに渡す引数の型によって継承した元のメソッドか、派生したメソッドの処理を行うか振り分け、処理内容を分岐させているのだというような認識ですが、どなたか詳しく教えてください。

Answer 1

こんにちは。

三大要素とは別に動的束縛もメリットの一つだと目にしました。

Qiitaの記事が参照していると思われるWikipediaには下記注記があります。（ここ１年で追加された可能性もあります。）

ただし、カプセル化（可視性の定義）やポリモフィズムとダイナミックバインディングはオブジェクト指向言語に固有の概念というわけではなく、非オブジェクト指向言語の中にもこの性質を備えるものもある。

また、「動的束縛」について調べてみたけどはっきりしないですね。サイト毎に解釈が異なるようです。（動的ポリモーフィズム、動的型付けなどなど）

英語のWikipediaにDynamic binding (computing)からのリダイレクトでLate bindingがありました。
しかし、ここもはっきりしません。どうもプログラム動作中に名前で呼び出すメソッドを決定する仕組みと書かれているように読み取れます。そして、C++のv-tableを使う仕組みもその１つと書かれているようです。しかし、C++は名前でメソッドを動的に決定する仕組みを持ちません。

遅延バインディング(late binding, dynamic binding)と事前バインディング(early binding)に英語のWikipediaと似たことが書かれてます。こちらは、名前で解決することは書かれてますが、C++については触れていません。

C++のv-tableを使う仕組みは動的ポリモーフィズムですから、普通にオブジェクト指向プログラミングですね。しかし、動的に名前でメソッドを決定する仕組みはオブジェクト指向に必須でもないし、オブジェクト指向以外の分野でもよく使われると思います。

「動的束縛」のオブジェクト指向的な側面は動的ポリモーフィズムであると理解しておけば十分ではないでしょうか？

Comments

[Zuishin]

C++ については「動的束縛の無い世界の挙動」と書いてありますので、除外していいのではないですか？ また、Wikipedia の v-table についても、動的束縛ではなく静的束縛についての記述です。

[KSwordOfHaste]

wikiの文章中ではC++の仮想関数はearly(static)bindingで、動的束縛でないものの例として挙がってるような気がしました。

それはともかく...

C++の仮想関数やJavaのインスタンスメソッドのような継承による解決に対して、変数に型を持たない動的型付け言語やテンプレートベース言語でのメソッド解決などは「設計の考え方が違ってくる」ため、それらを区別するなら意味を感じるように思います。なので単に実行時にメソッド解決するといわれても若干モヤモヤしました...w;

そうした色々な動的な解決をおおざっぱに纏めて「動的束縛」として(あちこちのページで)呼んでいるような印象があり、
> オブジェクト指向的な側面は動的ポリモーフィズムであると理解しておけば十分
この結論が自分にはしっくりきました。

[Chironian]

確かにv-tableを使う実装は、early bindingと書かれています。

しかし、その直後で、
2 Late binding implementations
2.3 Late binding in C++
として記載があり、2.3の中身はv-tableによる実装が書かれているように読み取れます。

正直、この英語版のWikipediaでさえ混乱しているように感じました。

[KSwordOfHaste]

言われてみればごもっともです。失礼しました。

[Zuishin]

動的束縛を実装するために v-table をこういう風に利用するということであって、v-table が動的束縛の実装ということではないと思います。ですから前もって静的束縛について書かれているのではないかと。

[Chironian]

Zuisinさん。

確かに、late bindingを（early bindingである）v-tableを使って実装すると書かれていると思います。
しかし、その方法が全くないのですよ。なので、単に矛盾した記述のように見えてしまいます。

[Zuishin]

https://ja.wikipedia.org/wiki/%E4%BB%AE%E6%83%B3%E9%96%A2%E6%95%B0%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB

ここにによると、early binding によって複数の v-table を作成し、それを動的に切り替えることで束縛を変更している処理系が多いようですね。

[Chironian]

なるほど。
early bindingはv-table生成部分を指し、v-table切り替えがlate bindingということですか！！
動的束縛を解説するのに、v-tableを使った一連の仕組みを２つに分けて言及するとは正直盲点でした。

しかし、C++が名前解決するのはコンパイル時なので、動的名前解決することが「動的束縛」の必要条件ならC++は含まれないし、必要条件でないならそもそも"the method (中略) is looked up by name at runtime"と言及する意味が分からないので、Wikipediaの説明が良く分からないのも事実かと。

恐らく、広義の動的束縛は名前に関係なく、動的にメソッドを切り替える方法で、動的ポリモーフィズムやC言語の関数ポインタも含むような仕組み、狭義の動的束縛は名前を使って動的にメソッドを切り替える仕組みでリフレクション等を指すということではないでしょうか？
Wikipediaの解説はこれらをごっちゃにしているので、わけが分からなくなっているということのような気がします。

[Zuishin]

おっしゃる通りややこしいですね。厳密に言おうとすると微妙な部分もある気がします。

[King_of_Flies]

割り込もうとしたんですが、会話内容についていけず・・・・orz
ただ分かったのが「明確な答え」は所在不明といったところでしょうか。

遅延バインディングで覚えておけばよいのでしょうか・・・

[Chironian]

動的（遅延）バインディング について、広く受け入れられている明確な定義が存在しないのは間違いないと思います。（あればあんなに混乱することはありえません。）

ただ、「関数呼び出しと実際に呼び出される関数をどのようにして決めるのか？」と言う仕組みの１つであることは間違いなさそうです。
オブジェクト指向の動的ポリモーフィズムでも使われますが、それは応用の1つに過ぎず、他のケースでも使われます。
つまり、オブジェクト指向のメリットではありませんから、オブジェクト指向のメリットの１つとして理解しようとさえしなければ、特に難しい概念でもないと思います。

[King_of_Flies]

ふむ。
結局行き着いたのは、「関数呼び出しと実際に呼び出される関数をどのようにして決めるのか？」という一点のみで、他の部分の情報は補足情報程度に思っていればよいということですね。

そしてそもそも動的バインディングはオブジェクト指向のメリットというわけではなく、オブジェクト指向という中にもあるし、他の箇所でも応用的に使われているものということですね！
なるほどなるほど

Answer 2

遅延バインディングと同じ意味です。メソッドを呼び出した時にどのコードが動くかが実行時に決まることです。例えば動的言語や COM 呼び出しなどが該当します。

追記

マイクロソフト用語集での「dynamic binding」の意味

Binding (converting symbolic addresses in the program to storage-related addresses) that occurs during program execution. The term often refers to object-oriented applications that determine, during run time, which software routines to call for particular data objects.

訳:
束縛(プログラムの記号アドレス(アドレスを記号であらわしたもの)をメモリの中のアドレスに変換すること) がプログラムの実行中に起こるもの。しばしば、特定のデータオブジェクトを呼ぶルーチンを実行中に決定するオブジェクト指向アプリケーションの用語として参照される。

意訳:
束縛というのは、プログラム中で定義された仮のアドレスを実アドレスに割り当てることで、それをコンパイル時や起動時ではなく実行中に動的に行うものを動的束縛と呼ぶ。動的型付言語の用語として使われることが多い。

#つまりどういうことか
これを読むと、ポリモーフィズムとは全く別の概念であることがわかります。しかしこれを実装するのにポリモーフィズムを使うのが便利なのでオブジェクト指向でよく採用される技術ですが、オブジェクト指向でなければ動的束縛ができないかというと、そんなことは全然ありません。
たとえば式指向の Lisp にも動的束縛はあります。

Comments

[Zuishin]

たとえば PowerShell で Excel を操作する場合は次のようにします。

$excel = new -com Excel.Application
$excel.Visible = $true

PowerShell は Excel.Application のプロパティもメソッドも事前に知らされていませんが、どちらも自由に使うことができます。ここでは Visible プロパティに $true を代入して Excel を見えるようにしています。
これが動的バインディングです。後からバインディングするので遅延バインディングとも言います。

メリットは見たままです。知らないオブジェクトの知らないメソッドを使うことができなければ、使う際に面倒な手続きが必要になるでしょうし、バージョンアップに対応できません。
それをこのような簡単な手続きで扱えるのは動的バインディングができるからです。

[King_of_Flies]

バージョンアップに強いのと使いやすいのがメリットですか？
自由度が高い呼び出しって、しっかりと管理しなければちょっと怖いかな・・・と思うのですが。
どうでしょう？

[Zuishin]

怖いというのはどういう意味でですか？
静的だろうが動的だろうが公開されたメソッドを自由に使うということに関して変わりないように思います。

[King_of_Flies]

簡単な話で型の意識をあまりしなくても組み込めてしまうわけですから、
呼出し後の型で混乱しそうです・・・

[Zuishin]

混乱するかしないかは慣れかもしれませんね。スクリプトを書く人はゆるい型付けに慣れています。

Answer 3

オブジェクト指向プログラミングは、オブジェクト指向という考え方を実現するためのプログラミング方式のことです。
ですので「オブジェクト指向という考え方で何を実現したいのか」を理解しないままコードから考えると、行き詰り易いかと思います。

ここから例示して考えていきたいと思いますが、例えば犬、猫、鳥などを扱うペットショップがあるとします。ある日、商品であるペット達がとある病気にかかっていないかという検査で、獣医師がやってきて動物１匹ずつ順に鳴かせるということをしたいとします。

上記をモデル化しオブジェクト指向プログラミングで一匹ずつ鳴かせるという動作を実現するコードを検討してみましょう。

動物クラスを継承した犬、猫、鳥クラスがあり、それぞれ「鳴く」というメソッドがあるとします。
例えば鳴かせるだけでいいのであれば、現実の世界のイメージであれば、お店のケージを順に巡り、１匹ずつ鳴かせればいいと想像できます。中に入っている動物が何であれ、鳴くことができるのであれば順に鳴かせればいいですね。勿論、売り場の設計上、ある程度は犬、猫、鳥と順番にケージを回ることになるかもしれませんが、重要なのは個々の動物がなんであるかを意識する必要は無いということです。

プログラミングとしてそれを実施したければ、配列Ａの中に犬、猫、鳥クラスを順不同で格納していって、順番にループさせて鳴くメソッドを実行するというコードがイメージできます。
配列Ａの中身は、「鳴く」メソッドが存在するのであればどんなオブジェクトが格納されていても問題ありません。

・・・というようなことが「オブジェクト指向でやりたいこと」です。現実世界のイメージに則って考えられているということが分かるかと思います。

ですが、プログラミングコード上の事情により、例えば犬、猫、鳥クラスで別々の配列Ｘ、Ｙ、Ｚを作らなければならないとします。
それはそれで、それがプログラミング上のルールであればプログラマーはそれに従ってコーディングするのですが、上記のようなことを想像すると、**そういうルールがあるということが果たしてオブジェクト指向に則っているか？**ということになるわけです。
かくして、上記のようなことを実現する「ダイナミックバインディング」という概念が産み出され、その概念はオブジェクト指向プログラミングを構成するための１条件として数えられるようになります。

メリットはオブジェクト指向プログラミングの実現です。デメリットはオブジェクト指向プログラミングが実現できないことです。
私は無理に使うことを考えたりはしませんが、使いたいような設計をする機会があったときにそういう機能が使えるということは立派なメリットです。

私はそんな感じで理解しています。私見も入っているかと思いますが参考になれば。