AN INVITATION TO EIFFEL

8 継承

　継承は、これまで述べたこととは別の基礎的な一般化の機構であり、無からというよりもむしろ既存のクラス群の組み合わせ<combination>と特殊化<specialization>によって、新たなクラスを定義することを可能にします。

　次の単純な例は、EiffelBaseのデータ構造ライブラリからのもので、典型的なものです。 LIST は、例に示されたように、どんな意味の表現でもリストを記述します。このような表現の一つは、もしリストが固定数の要素を持つならば、配列を使用します。私たちは、次のように、LIST と ARRAY の組み合わせによって、対応するクラスを定義することもできます。

class ARRAYED_LIST [G] inherit



LIST [G];



ARRAY [G]

export ... See below ... end

feature



... 固定サイズのリストに固有な特徴 ...



end -- class ARRAYED_LIST

　inherit...句には、新たなクラスのすべての "親" を並べます。この並びは、それらの "継承者<heir>" と呼ばれます（クラスの "祖先" は、そのクラス自体、その親、祖父母などを含みます。逆の用語は、"子孫" です）。例で示したように ARRAYED_LIST を宣言することは、リストと配列のすべての特徴と特性が固定サイズのリストへも同じく適用できる、ということを保証します。このクラスは二つ以上の親を持つから、これは 多重 継承の事例です。

　次の標準的な図による慣例<convention>は、このような継承構造を示します。

継承構造

　ARRAYED_LIST のような継承者クラスは、それ自体の公開<export>方針を定義する能力を必要とします。デフォルトでは、継承された特徴は、それらの公開状態（公的に利用可能、秘密、選択されたクラスへだけ利用可能）を維持しますが、これは継承者で変更してもかまいません。ここで、たとえば、ARRAYED_LIST は、ARRAYED_LIST のクライアントへは直接利用できない ARRAY の特徴をなしている、LIST の公開された特徴だけを公開することになります。これを達成するための構文は、次のように簡単です。

class ARRAYED_LIST [G] inherit



LIST [G];



ARRAY [G]

export {NONE} all end

... The rest as above ...

　多重継承のもう一つの例は、EiffelVision の実際のクラス群に近い、クラス WINDOW に基づくウィンドウ システムから来ます。ウィンドウは、高さ、幅、位置、ウィンドウの大きさを変更したり移動したりするルーチン、他のグラフィカルな操作といった、グラフィカルな特徴を持ちます。システムは、ウィンドウに入れ子となることを許しているので、ウィンドウもまた、サブウィンドウを追加し、サブウィンドウを削除し、別の親ウィンドウへアタッチするなどの、サブウィンドウと親ウィンドウへのアクセスといった、階層的な特徴を持ちます。これらの特徴のすべてについて、特有な実装を包含するであろう複雑なクラスを書くというよりも、すべての階層的な特徴を TREE （木構造を記述している EiffelBase 内のクラス）から、すべてのグラフィカルな特徴をクラス RECTANGLE から、継承することが好ましいです。

　継承は、努力 -- 分析、設計、実装、あるいは発展<evolution>であろうとなかろうと -- の顕著な経済性をもたらし、そしてソフトウェア開発プロセス全体に関して深い効果があります。

　継承の非常な威力は、それを制御下においておくために、何らかの方法を要求します。多重継承は、特に、異なる親から継承した特徴間の名前の衝突について疑問を上げます。この事例は、特に、独立した開発者の貢献によって提供されたクラスについて、必然的に、実際に持ち上がるでしょう。このような名前の衝突は、次のように、名前を変更すること<rename>を通じて、取り除くこともできます。

class C inherit



A rename x as x1, y as y1 end



B rename x as x2, y as y2 end



feature...

　ここで、もし A と B の両方が x と y と名付けられた特徴を持つならば、クラス C は、名前の変更無しでは、無効になるでしょう。

　また、名前の変更は、子孫において、より適した機能の名前を提供するのに寄与します。たとえば、クラス WINDOW は、ルーチン insert_subtree を TREE から継承することもできます。しかしながら、WINDOW のクライアントにとっては、そのようなルーチンの名前は、もはや適していません。このクラスをウィンドウ操作のために使用するアプリケーションは、首尾一貫したウィンドウの用語を必要とし、このクラスの実装へ導いた継承構造に関係していてはいけません。それで、あなたは、insert_subtree という名前を、WINDOW の inherit 句で、add_subwindow という名前に変更したいと願うかもしれません。

　多重継承の機構を間違って使用することに対して保護するさらなるファシリティとして、すべての親クラスの不変条件は、自動的に、新たに定義されるクラスへ適用します。それで、クラスは、もし不変条件が互換でなければ、結合してはいけません。