Loading article…
ソフトウェアエンジニアリングにおいて、ダブルディスパッチはマルチディスパッチの特殊な形式であり、呼び出しに関与する2つのオブジェクトの実行時型に応じて、関数呼び出しを異なる具体的な関数にディスパッチするメカニズムです。ほとんどのオブジェクト指向システムでは、コード内の関数呼び出しから呼び出される具体的な関数は、単一のオブジェクトの動的型に依存するため、これらはシングルディスパッチ呼び出し、または単に仮想関数呼び出しと呼ばれます。
ダン・インガルスは、 Smalltalkでダブルディスパッチを使用する方法を最初に説明し、それを多重多態性（multiple polymorphism）と呼んだ。[ 1 ]
ここで取り上げる一般的な問題は、受信者だけでなく引数に応じて、メッセージを異なるメソッドにディスパッチする方法である。
そのため、CLOSのようなシステムは多重ディスパッチを実装している。二重ディスパッチは、多重ディスパッチをサポートしていないシステムにおいて、ポリモーフィズムを段階的に低減させるもう一つの解決策である。
ダブルディスパッチは、計算の選択が引数の実行時型に依存する状況で役立ちます。たとえば、プログラマーは次のような状況でダブルディスパッチを使用できます。
schedule場合があります。会計士として分類された人物オブジェクトと、エンジニアリングとして分類された仕事オブジェクトが与えられた場合、アルゴリズムはその人物をその仕事に割り当てることを拒否します。上記の例で示したように、一般的な慣用表現では、実行時に呼び出しの引数の型に基づいて適切なアルゴリズムが選択されます。そのため、呼び出しは、通常、単一メソッドディスパッチのみをサポートする言語よりも、呼び出しの動的解決に伴う通常の追加パフォーマンスコストの影響を受けます。たとえば、C++では、動的な関数呼び出しは通常、単一のオフセット計算によって解決されます。これは、コンパイラがオブジェクトのメソッド テーブル内の関数の位置を知っているため、オフセットを静的に計算できるため可能です。ダブルディスパッチをサポートする言語では、コンパイラが実行時にメソッド テーブル内のメソッドのオフセットを計算するコードを生成する必要があるため、全体の命令パスの長さが増加します(関数への呼び出しの総数を超えることはほとんどなく、それほど大きな問題ではない可能性があります)。
一般的な使用例としては、ディスプレイポートにオブジェクトを表示することが挙げられます。ディスプレイポートは、スクリーンやプリンター、あるいはまだ存在しない全く別のものかもしれません。これは、そうした様々なメディアを扱うための素朴な実装例です。
class Rectangle def display_on ( port ) # オブジェクトクラスに基づいて適切なコードを選択しますcase port when DisplayPort # DisplayPort に表示するためのコードwhen PrinterPort # PrinterPort に表示するためのコードwhen RemotePort # RemotePort に表示するためのコードend end end楕円、三角形、その他媒体上に自身を表示したいオブジェクトについても同様のコードを作成する必要があり、新しいタイプのポートが作成される場合は、すべて書き直す必要があります。問題は、オブジェクトに display_on メソッドをディスパッチするためのものと、表示に適したコード（またはメソッド）を選択するためのものの2つの多態性が存在することです。
よりクリーンで保守しやすい解決策は、2回目のディスパッチを行い、今度は媒体上にオブジェクトを表示するための適切な方法を選択することです。
class Rectangle def display_on ( port ) # 2 番目のディスパッチport . display_rectangle ( self ) end endclass Oval def display_on ( port ) # 2 番目のディスパッチport . display_oval ( self ) end endclass DisplayPort def display_rectangle ( object ) # DisplayPort に長方形を表示するコードend def display_oval ( object ) # DisplayPort に楕円を表示するコードend # ... endclass PrinterPort def display_rectangle ( object ) # PrinterPort に長方形を表示するコードend def display_oval ( object ) # PrinterPort に楕円を表示するコードend # ... end一見すると、ダブルディスパッチは関数オーバーロードの自然な結果のように思えます。関数オーバーロードでは、呼び出される関数が引数の型に依存するようになります。しかし、関数オーバーロードはコンパイル時に「名前マングリング」を使用して行われ、関数の内部名が引数の型をエンコードします。たとえば、関数は内部的に__foo_ifoo(int)と呼ばれ、関数は__foo_dと呼ばれる場合があります。したがって、名前の衝突も仮想テーブルのルックアップも発生しません。対照的に、動的ディスパッチは呼び出し元のオブジェクトの型に基づいており、関数オーバーロードの代わりに仮想関数（オーバーライド）を使用するため、vtable のルックアップが発生します。C ++で記述されたゲームにおける衝突の次の例を考えてみましょう。foo(double)
class Spaceship {}; class ApolloSpacecraft : public Spaceship {};class Asteroid { public : virtual void collideWith ( Spaceship & ) { std :: println ( "小惑星が宇宙船に衝突しました" ); }virtual void collideWith ( ApolloSpacecraft & ) { std :: println ( "小惑星がアポロ宇宙船に衝突しました" ); } };class ExplodingAsteroid : public Asteroid { public : void collideWith ( Spaceship & ) override { std :: println ( "ExplodingAsteroid が宇宙船に衝突しました" ); }void collideWith ( ApolloSpacecraft & ) override { std :: println ( "ExplodingAsteroid が ApolloSpacecraft に衝突しました" ); } };もしあなたが以下のいずれかに該当する場合：
小惑星；宇宙船；アポロ宇宙船；そして、関数オーバーロードのため、
小惑星.collideWith (宇宙船);小惑星.collideWith (アポロ宇宙船) ;それぞれ、動的ディスパッチを使用せずに、Asteroid hit a Spaceshipとを出力します。さらに：Asteroid hit an ApolloSpacecraft
ExplodingAsteroid explodingAsteroid ; explodingAsteroid . collideWith ( spaceship ); explodingAsteroid . collideWith ( apolloSpacecraft );それぞれを出力しますExplodingAsteroid hit a SpaceshipがExplodingAsteroid hit an ApolloSpacecraft、これも動的ディスパッチは使用しません。
を参照する場合Asteroid、動的ディスパッチが使用され、次のコードが実行されます。
小惑星& asteroidRef = explodingAsteroid ; asteroidRef.collideWith ( spaceship ) ; asteroidRef.collideWith ( apolloSpacecraft ) ;と が出力されExplodingAsteroid hit a Spaceship、ExplodingAsteroid hit an ApolloSpacecraftこれも予想通りです。しかし、次のコードは期待どおりに動作しません。
Spaceship & spaceshipRef = apolloSpacecraft ; asteroid . collideWith ( spaceshipRef ); asteroidRef . collideWith ( spaceshipRef );望ましい動作は、これらの呼び出しをapolloSpacecraft、変数のインスタンス化された型である引数を受け取る関数にバインドすることです。つまり、期待される出力は と になりますAsteroid hit an ApolloSpacecraft。ExplodingAsteroid hit an ApolloSpacecraftしかし、実際の出力はAsteroid hit a SpaceshipとですExplodingAsteroid hit a Spaceship。問題は、仮想関数は C++ で動的にディスパッチされるのに対し、関数オーバーロードは静的に行われることです。
上記の問題は、例えばビジターパターンを使用して、ダブルディスパッチをシミュレートすることで解決できます。既存のコードを拡張して、と両方に関数を与えるようにします。SpaceshipApolloSpacecraft
virtual void collideWith ( Asteroid & asteroid ) { asteroid.collideWith ( * this ) ; }そして、前の例はまだ正しく動作しませんが、宇宙船をエージェントとして呼び出しを再構成すると、望ましい動作が得られます。
Spaceship & spaceshipRef = apolloSpacecraft ; Asteroid & asteroidRef = explodingAsteroid ; spaceshipRef . collideWith ( asteroid ); spaceshipRef . collideWith ( asteroidRef );Asteroid hit an ApolloSpacecraft予想通り、 とが出力されますExplodingAsteroid hit an ApolloSpacecraft。重要なのは、 がspaceshipRef.collideWith(asteroidRef);実行時に次のことを行う点です。
spaceshipRefは参照なので、C++ は vtable から正しいメソッドを検索します。この場合、 が呼び出されますApolloSpacecraft::collideWith(Asteroid&)。ApolloSpacecraft::collideWith(Asteroid&)、asteroidは参照であるため、別のvtableルックアップasteroid.collideWith(*this)が発生します。この場合、はへの参照であるため、が呼び出されます。asteroidExplodingAsteroidExplodingAsteroid::collideWith(ApolloSpacecraft&)C#では、引数を受け取るインスタンス メソッドを呼び出す際に、ビジター パターンを使用せずに多重ディスパッチを実現できます。これは、従来のポリモーフィズムを使用しながら引数をdynamic 型にキャストすることによって実現されます。[ 3 ]ランタイム バインダーは、実行時に適切なメソッド オーバーロードを選択します。この決定では、オブジェクト インスタンスの実行時型 (ポリモーフィズム) と引数の実行時型の両方が考慮されます。
Eiffelプログラミング言語は、エージェントの概念を二重ディスパッチ問題に適用することができます。以下の例は、エージェント言語の構成要素を二重ディスパッチ問題に適用したものです。
様々な形式のSHAPEと、SHAPEを描画するための描画サーフェスが存在する問題領域を考えてみましょう。SHAPEとSURFACEはどちらも、それぞれ独自の`draw`関数を認識していますが、互いの関数については認識していません。ここでは、これら2種類のオブジェクトが、ビジターパターンを用いたダブルディスパッチで共変的に相互作用するようにしたいと考えています。
課題は、多形性を持つサーフェスが、そのサーフェス上に多形性を持つ形状を描画するようにすることです。
以下の出力例は、2 つの SURFACE ビジター オブジェクトが、多態的な SHAPE オブジェクトのリストを介して多態的に渡された結果を示しています。ビジター コード パターンは、SHAPE と SURFACE を汎用的に認識するだけで、それぞれの具体的な型は認識しません。代わりに、このコードは実行時多態性とエージェントのメカニズムを利用して、これら 2 つの遅延クラスとその子孫クラス間の非常に柔軟な共変関係を実現しています。
エッチスケッチに赤い多角形を描くGRAFFITI_WALLに赤い多角形 を描画するETCHASKETCHに灰色の長方形 を描くGRAFFITI_WALL 上に灰色の長方形 を描画するETCHASKETCHに緑色の四角形 を描くGRAFFITI_WALL に緑色の四角形 を描画するETCHASKETCHに青色の平行四辺形 を描きますGRAFFITI_WALLに青い平行四辺形 を描くエッチスケッチに黄色の多角形 を描くGRAFFITI_WALLに黄色の多角形 を描画するETCHASKETCHに紫色の長方形 を描きますGRAFFITI_WALL 上に紫色の長方形 を描く
SHAPEやSURFACEを検討する前に、まず、ダブルディスパッチの高度な分離利用について検討する必要があります。
ビジターパターンは、ビジターオブジェクトがデータ構造（リスト、ツリーなど）の要素を多態的に訪問し、訪問した対象構造内の多態的な要素オブジェクトに対して何らかのアクション（呼び出しまたはエージェント）を適用することによって機能します。
以下の例では、多相的なSHAPEオブジェクトのリストを作成し、多相的なSURFACEを使用してそれぞれのオブジェクトを訪問し、SHAPEをSURFACE上に描画するように要求します。
作る表面に図形を印刷する。地元l_shapes : ARRAYED_LIST [ SHAPE ]l_surfaces : ARRAYED_LIST [ SURFACE ]するl_shapesを作成します。make ( 6 )l_shapes.extend ( create { POLYGON } .make_with_color ( " red" ) )l_shapes.extend ( create { RECTANGLE } .make_with_color ( " grey" ) )l_shapes.extend ( create { QUADRILATERAL } .make_with_color ( " green" ) )l_shapes.extend ( create { PARALLELOGRAM } .make_with_color ( " blue" ) )l_shapes.extend ( create { POLYGON } .make_with_color ( " yellow" ) )l_shapes.extend ( create { RECTANGLE } .make_with_color ( " purple" ) )l_surfacesを作成します。make ( 2 )l_surfaces.extend ( create { ETCHASKETCH } .make )l_surfaces.extend ( create { GRAFFITI_WALL } .make )l_shapesをic_shapesとしてループしますl_surfacesをic_surfacesとしてループするic_surfaces.item.drawing_agent ( ic_shapes.item.drawing_data_agent )終わり終わり終わりまず、SHAPEオブジェクトとSURFACEオブジェクトのコレクションを作成します。次に、一方のリスト（SHAPE）を反復処理し、もう一方のリスト（SURFACE）の要素がそれぞれのリストを順番に訪問できるようにします。上記のサンプルコードでは、SURFACEオブジェクトがSHAPEオブジェクトを訪問しています。
このコードは、`drawing_agent` を介して {SURFACE}.draw に対して間接的にポリモーフィックな呼び出しを行います。これは、ダブルディスパッチパターンの最初の呼び出し（ディスパッチ）です。間接的かつポリモーフィックなエージェント（`drawing_data_agent`）を渡すことで、ビジターコードが次の 2 つのことだけを知ることができるようになります。
SURFACEとSHAPEはそれぞれ独自のエージェントを定義しているため、ビジターコードは、ポリモーフィックな呼び出しであろうとなかろうと、適切な呼び出しを知る必要がなくなります。このような間接化と疎結合は、C、C++、Javaなどの他の一般的な言語では、何らかのリフレクションやシグネチャマッチングによる機能オーバーロードを用いない限り、実現できません。
{SURFACE}.draw へのポリモーフィック呼び出しの中にはエージェントへの呼び出しがあり、これがダブルディスパッチパターンにおける 2 番目のポリモーフィック呼び出しまたはディスパッチとなります。
延期されたクラス表面機能{なし} -- 初期化作る-- Current を初期化します。するdrawing_agent := agent draw終わり機能-- アクセスdrawing_agent : PROCEDURE [ ANY , TUPLE [ STRING , STRING ]]-- Currentの描画エージェント。機能{なし} -- 実装draw ( a_data_agent : FUNCTION [ ANY , TUPLE , TUPLE [ name , color : STRING ]] )-- Current 上に `a_shape` を描画します。地元l_result :タプル[ name , color : STRING ]するl_result := a_data_agent ( Void )print ( """ + l_result.color + " "" + l_result.name + "を" + type + " % N "に描画します" )終わり型:文字列-- Current の名前を入力してください。延期された終了終わり19行目のエージェント引数と24行目の呼び出しは、どちらもポリモーフィックかつデカップリングされています。エージェントがデカップリングされているのは、{SURFACE}.draw機能が`a_data_agent`がどのクラスに基づいているかを知らないためです。操作エージェントがどのクラスから派生したかを判断する方法がないため、SHAPEやその子孫クラスから派生する必要はありません。これは、他の言語の単一継承、動的バインディング、ポリモーフィックバインディングに比べて、Eiffelエージェントの明確な利点です。
エージェントは実行時に動的に多態性を持ちます。これは、オブジェクトが必要になった瞬間に動的に作成され、その時点でオブジェクト化されたルーチンのバージョンが決定されるためです。唯一強く結び付けられている知識は、エージェントシグネチャのResult型、つまり2つの要素を持つ名前付きTUPLEです。ただし、この特定の要件は、囲んでいる機能の要求に基づいています（たとえば、25行目ではTUPLEの名前付き要素を使用してSURFACEの`draw`機能を実現しています）。これは必要不可欠であり、回避されていません（そしておそらく回避できないでしょう）。
最後に、`drawing_agent`機能のみが任意のクライアントにエクスポートされる点に注目してください。これは、ビジターパターンコード（このクラスの唯一のクライアント）は、エージェントに関する情報さえあれば、そのタスク（例えば、訪問対象オブジェクトに適用される機能としてエージェントを使用するなど）を実行できることを意味します。
SHAPEクラスは、描画対象（例えば、サーフェス上）の基盤（描画データなど）を提供しますが、必ずしもサーフェス上である必要はありません。ここでも、エージェントは、SHAPEとの共変関係を可能な限り分離するために必要な間接参照とクラス非依存の機能を提供します。
さらに、SHAPEは`drawing_data_agent`のみをクライアントに完全にエクスポート可能な機能として提供している点にご注意ください。したがって、作成以外のSHAPEとのやり取りは、`drawing_data_agent`の機能を通してのみ可能です。`drawing_data_agent`は、あらゆるクライアントがSHAPE用の図面データを間接的かつ多形的に収集するために使用されます。
延期されたクラス形機能{なし} -- 初期化make_with_color ( a_color : like color )-- `a_color` を `color` として使用します。するcolor := a_colordrawing_data_agent := agent drawing_data確保するcolor_set : color.same_string ( a_color )終わり機能-- アクセスdrawing_data_agent : FUNCTION [ ANY , TUPLE , like drawing_data ]-- 描画用データエージェント。機能{なし} -- 実装drawing_data : TUPLE [ name : like name ; color : like color ]-- 電流図の描画に必要なデータ。する結果:= [名前、色]終わり名前:文字列-- Current のオブジェクト名。延期された終了色:ストリング-- 現在の色。終わり古典的な宇宙船の例のバリエーションとして、1つまたは複数の宇宙船オブジェクトが、浮遊小惑星や宇宙ステーションなどの他のオブジェクトで満たされた宇宙空間をさまよっているというものがあります。ここで必要なのは、架空の宇宙空間における2つの共変オブジェクト間の遭遇（例えば衝突の可能性）を処理するための二重ディスパッチ方式です。以下の例では、USSエンタープライズとUSSエクセルシオールの出力エクスカーションは次のようになります。
宇宙船エンタープライズ号の位置がA-001からA-002に移動する。 宇宙船エンタープライズ号は回避行動を取り、小惑星「ローグ1」を回避した！ 宇宙船エンタープライズ号の位置がA-002からA-003に変更されます。 宇宙船エンタープライズ号は回避行動を取り、小惑星「ローグ2」を回避した！ 宇宙船エンタープライズ号は、通過する際に科学チームを宇宙船エクセルシオール号へ転送する！ 宇宙船エンタープライズ号の位置がA-003からA-004に変更されます。 宇宙船エクセルシオールの位置がA-003からA-005に変更されました。 宇宙船エンタープライズ号は回避行動を取り、小惑星「ローグ3」を回避した！ 宇宙船エクセルシオールはディープスペース9宇宙ステーションの近くにあり、ドッキング可能です。 宇宙船エンタープライズ号の位置がA-004からA-005に変更されます。 宇宙船エンタープライズ号は、通過する際に科学チームを宇宙船エクセルシオール号へ転送する！ 宇宙船エンタープライズ号はディープスペース9宇宙ステーションの近くにあり、ドッキング可能です。 古典的な宇宙船の例における訪問者も、二重派遣機構を備えている。
作る-- 宇宙船オブジェクトが宇宙内を訪れ、移動できるようにする。地元l_universe : ARRAYED_LIST [ SPACE_OBJECT ]l_enterprise 、l_excelsior :宇宙船するl_enterpriseを作成します。make_with_name ( " Enterprise " , "A-001 " )create l_excelsior . make_with_name ( "Excelsior" , "A-003" )l_universeを作成します。make ( 0 )l_universe 。強制( l_enterprise )l_universe.force ( create { ASTEROID } .make_with_name ( " Rogue 1" , "A-002" ) )l_universe.force ( create { ASTEROID } .make_with_name ( " Rogue 2" , " A-003" ))l_universe 。力( l_excelsior )l_universe.force ( create { ASTEROID } .make_with_name ( "Rogue 3" , " A-004" ) )l_universe.force ( create { SPACESTATION } .make_with_name ( " Deep Space 9" , "A-005" ) )訪問( l_enterprise 、l_universe )l_enterprise.set_position ( "A - 002 " )訪問( l_enterprise 、l_universe )l_enterprise.set_position ( "A- 003 " )訪問( l_enterprise 、l_universe )l_enterprise.set_position ( "A- 004 " )l_excelsior.set_position ( "A - 005 " )訪問( l_enterprise 、l_universe )訪問( l_excelsior 、l_universe )l_enterprise.set_position ( "A - 005 " )訪問( l_enterprise 、l_universe )終わり機能{なし} -- 実装訪問( a_object : SPACE_OBJECT ; a_universe : ARRAYED_LIST [ SPACE_OBJECT ] )-- `a_object` が `a_universe` を訪問します。するa_universeをic_universeループとして横断する添付されている{ SPACE_OBJECT } ic_universe . item をal_universe_objectとしてチェックします。a_object.encounter_agent.call ( [ al_universe_object.sensor_data_agent ] )終わり終わり終わり二重ディスパッチは35行目に見られ、2つの間接エージェントが連携して、互いに完全に多相的に協調して動作する2つの共変呼び出しを提供しています。`visit`機能の`a_object`には`encounter_agent`があり、これは`al_universe_object`から取得した`sensor_data_agent`のセンサーデータで呼び出されます。この例のもう1つの興味深い点は、SPACE_OBJECTクラスとその`encounter`機能です。
SPACE_OBJECT のエクスポートされる機能は、遭遇とセンサーデータのエージェント、および新しい位置を設定する機能のみです。宇宙空間の各オブジェクトを 1 つのオブジェクト (宇宙船) が訪問すると、センサーデータが収集され、訪問中のオブジェクトの遭遇エージェントに渡されます。そこで、sensor_data_agent からのセンサーデータ (つまり、sensor_data_agent クエリによって返される sensor_data TUPLE のデータ要素項目) が現在のオブジェクトに対して評価され、その評価に基づいてアクションが実行されます (下記の SPACE_OBJECT の `encounter` を参照)。その他のデータはすべて {NONE} にエクスポートされます。これは、C、C++、Java の Private スコープに似ています。エクスポートされない機能として、データとルーチンは各 SPACE_OBJECT の内部でのみ使用されます。最後に、`print` への遭遇呼び出しには、SPACE_OBJECT の可能な子孫クラスに関する具体的な情報は含まれないことに注意してください。このレベルの継承において見られるのは、一般的な SPACE_OBJECT の属性とルーチンから得られる情報に基づいた、一般的な関係性のみです。`print` の出力が、宇宙船、宇宙ステーション、小惑星について私たちが知っていることや想像していることに基づいて、人間として意味を成すのは、単なる論理的な計画か偶然に過ぎません。SPACE_OBJECT には、その子孫に関する特定の知識はプログラムされていません。
延期されたクラス宇宙物体機能{なし} -- 初期化make_with_name ( a_name :名前に類似; a_position :位置に類似)-- Current を `a_name` と `a_position` で初期化します。するname := a_nameposition := a_positionsensor_data_agent := agent sensor_dataencounter_agent :=エージェントとの遭遇確保するname_set : name.same_string ( a_name )position_set : position.same_string ( a_position )終わり機能-- アクセスencounter_agent :プロシージャ[ ANY , TUPLE ]-- Currentとの遭遇を管理するためのエージェント。sensor_data_agent : FUNCTION [ ANY , TUPLE , attached like sensor_data_anchor ]-- Currentのセンサーデータを返すエージェント。機能-- 設定set_position ( a_position : like position )-- `position` を `a_position` で設定します。するprint ( type + " " + name + " の位置が " + position + " から " + a_position + ".%N"に変更されます)position := a_position確保するposition_set : position.same_string ( a_position )終わり機能{なし} -- 実装encounter ( a_sensor_agent : FUNCTION [ ANY , TUPLE , attached like sensor_data_anchor ] )-- Current と `a_radar_agent` の衝突状態を検出し、報告します。するa_sensor_agent.call ( [ Void ] )添付ファイル{のようなsensor_data_anchor } a_sensor_agent . last_result をal_sensor_dataとしてチェックし、もしname がal_sensor_data のnameと同じ文字列でない場合、if ( position . same_string ( al_sensor_data . position )) thenif (( al_sensor_data . is_dockable and is_dockable ) and( is_mannedおよびal_sensor_data.is_manned )および( is_maneuverableかつal_sensor_data.is_not_maneuverable ) ) thenprint ( type + " " + name + " は " + al_sensor_data . type + " " +に近いal_sensor_data.name + "ドッキング可能です。%N " )elseif (( is_dockable and al_sensor_data . is_dockable ) and( is_mannedおよびal_sensor_data.is_manned )および( is_maneuverableかつal_sensor_data.is_maneuverable ) ) thenprint ( type + " " + name + " 科学チームを " + al_sensor_data . type + " " +al_sensor_data.name + "通過する時!%N " )elseif ( is_manned and al_sensor_data . is_not_manned ) thenprint ( type + " " + name + " 回避行動を取り、 " + を回避しますal_sensor_data.type + " ` " + al_sensor_data.name + "'!% N " )終わり終わり終わり終わり終わり名前:文字列-- 現在の名称。型:文字列-- 電流の種類。延期終わり位置:文字列-- 現在の位置。is_dockable :ブール値Currentは他の有人物体とドッキング可能ですか？延期終わりis_manned :ブール値-- Currentは有人物体ですか？延期終わりis_maneuverable :ブール値電流は移動可能ですか？延期終わりsensor_data : sensor_data_anchorのように添付されています-- 電流のセンサーデータ。する結果:= [名前、タイプ、位置、ドッキング可能、ドッキング不可、有人、有人不可、操縦可能、操縦不可]終わりsensor_data_anchor : detachable TUPLE [ name , type , position : STRING ; is_dockable , is_not_dockable , is_manned , is_not_manned , is_maneuverable , is_not_maneuverable : BOOLEAN ]-- センサーデータ型アンカーは Current です。終わりSPACE_OBJECTには3つの子孫クラスがあります。
宇宙物体 小惑星宇宙船宇宙ステーションこの例では、ASTEROID クラスは「Rogue」アイテムに、SPACESHIP クラスは 2 隻の宇宙船に、SPACESTATION クラスはディープ・スペース・ナインに使用されています。各クラスで唯一の特殊化は、オブジェクトの「type」機能と特定のプロパティの設定です。「name」と「position」は作成ルーチンで指定されます。例: 以下は SPACESHIP の例です。
クラス宇宙船継承する宇宙物体作成する名前付きで作成機能{なし} -- 実装型: STRING = "Starship"-- <前駆者>is_dockable : BOOLEAN = True-- <前駆者>is_manned : BOOLEAN = True-- <前駆者>is_maneuverable : BOOLEAN = True-- <前駆者>終わりつまり、私たちの宇宙に存在する宇宙船はすべてドッキング可能で、有人かつ操縦可能です。小惑星などの他の物体は、これらのいずれにも該当しません。一方、宇宙ステーションはドッキング可能で有人ですが、操縦はできません。したがって、ある物体が別の物体と遭遇した場合、まず位置が互いに近接しているかどうかを確認し、近接している場合は、物体の基本特性に基づいて相互作用します。同じ種類と名前の物体は同じ物体とみなされるため、論理的に相互作用は許可されないことに注意してください。
ダブルディスパッチに関して、Eiffelは、クラスルーチンをエージェントとしてクラスから切り離し、直接オブジェクト機能呼び出しを行う代わりにエージェントを渡すことで、設計者とプログラマがオブジェクト間の直接的な知識をさらに排除できるようにします。エージェントには特定のシグネチャと可能な結果（クエリの場合）があり、特定のオブジェクトの詳細を放棄することなく、静的型チェックを行うのに理想的な手段となります。エージェントは完全にポリモーフィックであるため、生成されるコードはローカルなタスクを実行するために必要な特定の知識のみを持ちます。そうでない場合、特定の内部クラス機能の知識が多くの共変オブジェクトに分散されることによるメンテナンスの負担は発生しません。エージェントの使用とメカニズムがこれを保証します。エージェントを使用する際の潜在的な欠点の1つは、エージェントは直接呼び出しの場合よりも計算コストが高くなることです。この点を考慮すると、ダブルディスパッチでのエージェントの使用や、ビジターパターンでのエージェントの適用を前提とすべきではありません。共変相互作用に関わるクラスタイプの領域に関して設計上の制約が明確に把握できる場合、計算コストの観点からは直接呼び出しの方が効率的な解決策となります。しかし、参加するタイプのクラス領域が拡大したり、大きく異なったりすることが予想される場合は、エージェントを用いることで、ダブルディスパッチパターンにおける保守負担を軽減する優れた解決策となります。
、
オーバーロードの解決はコンパイル時ではなく実行時に行われます
。...