vieweditattachhistoryswikistopchangessearchhelp

多態性

polymorphism。ポリモーフィズム、ポリモルフィズム、多相性とも。

同種のアクセスに対して、オブジェクトごとに違った振る舞いをすること。その様子。--sumim


オブジェクト指向プログラミング（あるいはそれをサポートする言語）に必須とされる要素の一。他にカプセル化、継承。ただしこれは、ストラウストラップの考えをもとにした場合のオブジェクト指向（俗にクラス指向）に限った話であることについて、言及されることはあまりない。

参考：
--sumim

Squeak入門 第５章の Comanche フレームワークの説明で、Hello WorldなWebアプリケーションの例として

 process: request
     ^ 'Hello World!'
これだけです！‥‥‥単にStringを返しているだけなのに、どうして正しく処理されるのでしょうか。‥‥‥返ってきたオブジェクトに対してasHttpResponseTo:のメッセージを送るのです。‥‥‥Stringの場合は、以下のように実装されています。
 String>>asHttpResponseTo: request
     ^HttpResponse fromString: self
（‥‥‥以下略‥‥‥）

というくだり。
相手のクラスに応じて処理を分岐させるのに、相手のクラスにメソッドを追加するというのが驚きです。Stringなんて基本のクラスに自分の都合でメソッドを追加するのって、僕は抵抗を感じます。
CLOSの総称関数モデルならもっとエレガントに解決できると思いました。--SHIMADA

Smalltalk の学びにくさの原因のひとつかも知れませんね。--sumim

「ベストプラクティス パターン」を読んだら、Kent BeckもString>>asDate は気持ち悪い、Date>>fromString: を使うべき。っていってますね。--SHIMADA

SBPP32、ですね。ここにある、

  • 変換後のオブジェクトが変換前のオブジェクトとプロトコルを共有
  • それ以外に実装の方法がないとき

という asHoge を作る（選択するときの）条件はよく整理されていてなるほどなと思います。
“実現・実行が可能である”、つまり柔軟であることはシステムとしてとても大事だと思いますが、
それを用いるか否かの適切な判断を下せるかどうかの議論が続くべきであることを忘れてはいけないのでしょうね。
もちろん、机上の論議ではなく、ある程度、実地で経験を積んだ後…に。

Smalltalk のクラスライブラリの興味深いところはそこいらへんだと、
つまり、とりあえず多くのことを可能にしておいて、しばらく実際のシステムを
構築・運用してみる。そこで経験を蓄積し、パターンを抽出して他の（柔軟性の乏しい(^_^;)）環境に
適用してゆく…というような役回りと自身の進化のサイクルにある（あった）のではないかなと、感じ始めています。--sumim


大学の授業で多型性群体に関連した意味での polymorphism がでてきてぎくっっとしました。polymorphism と聞いて全然違うものを思い浮かべることもあるんですね(おや、これも polymorphism?)。polymorphism という語の初出はOEDによれば 1839年の"Fraser's magazine"、
"The various portraits of her majesty astonish by their perplexing polymorphism.."
だそうです(<-"Functions and data can dance as equal partners"中ほど)。女王様?? --pron

このページを編集 (3084 bytes)

Congratulations! 以下の 5 ページから参照されています。

This page has been visited 10015 times.