Delegation

• オブジェクト間で attribute を共有することができるプロトタイプベー ス言語は delegation ベースという。delegation は、オブジェクトやプロト タイプから、フィールドへのアクセスやメソッド呼び出しを他のオブジェクト へ間接的に処理することである。結果として、オブジェクトがもう一つのオブ ジェクトの拡張であるように見えるようにする。

• implicit delegation 継承 [49,121] の最もよく知られた形は、子オブ ジェクト(ホストオブジェクト)が、もう一つのオブジェクトを親オブジェクト (donor)とすることである。

• 実装として、親の attribute を持つことができ(図4-2)、子が親へのリ ンク (parent link) を持つことである。オブジェクトに親の attribute がない場合は、親を検索する。

• 以下のように $cell$ の子として $reCellImp'$ を定義する。 object cell: Cell is
    var contents: Integer:=0;
    method get(): Integer is
      return self .contents end;
    method set(n:Integer) is
      self .contents:=n end;
  end;
  object reCellImp':ReCell child of cell is
    var backup: Integer:=0;
    override set(n: Integer) is
      self .backup:= self .contents;
      delegate cell.set(n);
    end;
    method restore() is self .contents:=
      self .backup end;
  end;
  
• super .set(n) と書く代わりに delegate cell.set(n) と書く。 delegate cell.set(n) は、現在の self に束縛された self を持つ $cell$ の $set$ メソッドを実行する。

• delegate と embed の違いは、前者が、メソッド呼び出し の時に、親からメソッドを手に入れ、後者はより早く、オブジェクト生成時 に(親からのメソッド)を手に入れることを示す。

• $reCellImp'$ の定義は、embedding の $reCellImp$ の定義 (節 4.4)と似ている。しかし、意味は異なる。 reCellImp' は $cell$ の attribute の複製を含んでいない、しかしその代わり親へのリンクを持っ ている。親へのリンクにより $cell$ オブジェクトの attribute は、全て の子によって共有される。それゆえ、上の $reCellImp'$ は間違いである。一 つの $contents$ フィールドは、$cell$ の子かつ $reCellImp'$ のクローンによ り共有する。

• 回復可能な $cell$ のよりよい定義は、親の contents フィール ドを overriding するローカルの複製が必要である。 以下のように $reCellImp$ を定義することができる。 object reCellImp: ReCell child of cell is
    override contents: Integer:=cell.contents;
    var backup: Integer:=0;
    override set(n: Integer) is
      self .backup:= self .contents;
      delegate cell.set(n);
    end;
    method restore() is self .contents:=
      self .backup end;
  end;
  

• delegation 継承の重要な見方は self を持った 親へのリンクとの干渉である。 $reCellImp.get()$ の呼び出しにおいて、 $get$ メソッドは親 $cell$ にだけ存在する。しかし、$get$ コードの中に ある self の出現は original の受側を指す(親 $cell$ ではない)。

• よって $get()$ の返値としては $reCellImp$ の $contents$ フィー ルドに格納されている整数が望まれる。

• embedding では、子が delegation により構築された時は、 その親は静的に知ることができると仮定する。このような制約は、静的に型 付けされた delegation ベース言語(Cecil のような)に適用することができる。 子が親との適合性をチェックすることが重要である。

• 親のタイプを知るだけでは、健全性のためには十分ではない。例えば cell の contents フィールドが subsumption により忘れさられ、 子が タイプ $Boolean$ の $contents$ フィールドを持って定義されたとする と、子を通して呼び出される時に、継承された $get$ メソッドは original の受側としての self を解釈するために $Boolean$ を返す。 この結果は、間違いである。なぜなら $get$ メソッドの結果タイプは $Integer$ だからである。

• より一般的に、親が「真のタイプ」を静的に知っていても、どの オブジェクトかを特定できないかもしれない。他方、親がある attribute を 持たないことを静的に知らないに違いない。これらのオブジェクトは洗練され たタイプシステムにより実行されうる。ここでは単に親オブジェクトは静的に 知ることができると仮定する。

• 次に explicit delegation 継承を概観する。そこでは、オブジェクト は独立したメソッドを explicitly に他のオブジェクトに delegate し[80]、 親の宣言はない³。 以下のように書く。 object reCellExp: ReCell is
    var contents: Integer:=cell.contents;
    var backup: Integer:=0;
    method get(): Integer is return
      delegate cell.get() end;
    method set(n: Integer) is
      self .backup:= self .contents;
      delegate cell.set(n); end;
    method restore() is self .contents:=
      self .bakcup end;
  end;
  

• explicit delegation は、複数のオブジェクトへ操作を delegate する clean な方法を提供する。

• 複数 delegation は、複数の親をリストすることにより、時々 implicit delegation モデルでも提供される。implicit multiple 継承の場合は、 曖昧なメソッド lookup を引き起こすために問題がある。複数の親は explicit delegation により明らかに表現されなければならない。