vieweditattachhistoryswikistopchangessearchhelp

継承

inheritance

他のオブジェクトの仕様を受け継いで自分のもののように振る舞うこと。その実装。--sumim


C++方面で良く使われる言葉に、派生（derive）という言葉があります。--CUE


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

参考：
--sumim


Embedding による継承と Delegation による継承
継承と委譲の使い分け
委譲と継承の決定的な違いは何なんだ？
Inheritance is a static relationship


委譲との違いってなんなんでしょうね。＞継承　○○ *への* 委譲、○○ *からの* の継承かな…と方向性の問題かと思ったのですが、○○からの委譲、○○への継承もありうるからボツ。　個人的なイメージでは、継承は静的、委譲は動的というのがあるけれど…。--sumim

委譲は目的、継承は手段、という事でいいのではないでしょうか。
委譲するために継承という仕組みを使う、とは言えそうだけど、継承をするために委譲を使う、とは言わんでしょう。--CUE

目的と手段ということなら、継承が目的で委譲や組み込み（embedding）がその具体的手段だと思いはじめています。委譲によって本来自らが有しない機能を継承できる（継承のために委譲する）…と。--sumim

＞継承は静的
委譲を継承のひとつの手段だとすれば、こう思ったのは、Smalltalkにおけるスーパー- サブクラス間、クラス-インスタンス間の委譲関係を念頭に置いていたからかもしれません。Smalltalkにおいて継承は、静的委譲によって実現されている…と。（実務上はスパー-サブは動的なんですけど、暗示的にではありますが再コンパイルが必要ってことで本質としては静的という認識でいます）--sumim

＞目的と手段ということなら
うむむ、これは意外にはまりそうですね。
委譲が手段という事になると、いわゆる親子関係という言葉は使いづらくなってしまいますね：むろん、そういう喩えをする事自体に無理があるという考え方もできるわけですけども。
つまり、親のDNAが子に宿るのは、子が親から（あるいは親が子に）機能を継承をするのが目的ではないですよね：あ、いや待てよ、進化論的には継承をするのが目的でいいのか…。う〜ん。--CUE

利己的にはそうですね。さらに、この例では子は親の機能を継承するに際して、委譲ではなく、組み込みを使っているという、くしくも委譲＝手段、継承＝目的としたときの良くできた例です(^_^;)。でも、たぶん、逆、つまり委譲＝目的、継承＝手段とした具体例もありそうな気がします。--sumim

どっちが目的だとか手段だとかは言えないんじゃないかな。
それこそ「このたび、そう呼ぶ名前空間を作りましたので、皆様お越しくださいませ」っていうだけにしかならないと思う。
継承も委譲も、場所によってはそれを手段(実装っていうか)の名として呼んでいる(のを少なくとも俺は見たことがある)わけで。
きっと目的の例もどこかに有るのでしょう。 -戯

御意。＞委譲が目的の例
あとは名前空間と絡むかとも思いますが「狭い意味での…」と「広い意味での…」というのがあると思います。しかもそれらの間を埋める空間は連続であると。--sumim

＞「このたび、そう呼ぶ名前空間を作りましたので、皆様お越しくださいませ」
だとすると、「これは継承じゃなく委譲です」とか「これは委譲ではなく継承です」とか言う事ができなくなってしまうのでは：すべて発言者が自由に決めて良い事になってしまい、気持ち悪い。
ちゃんと、ネームに相応の意味と用法を与えてやりたいと思うのはわがままだろうか？--CUE

そりゃ、「これ」(および「これ」の内容のうちの部分要素)が何処の名前空間に属するか、に拠って答えは違ってくるでしょう。
つまり、「これ」の或る側面を見て「hogehogeです」「hogehogeではない」と言えたり言えなかったりする、という。
「これ」が常に点(しかも唯一の)を指しているだけなら、話は簡単だったんだろうけどね… -戯

＞ネームに相応の意味と用法
ネームはネームスペース(名前空間)に属さなくていいの？
＃俺自身がいいと思ってるかどうかはさておく。

＞わがまま
俺もそのわがままには賛同したいんだけど、既に現世が存在する以上、
「結局はこのWikiサイトでの意味と用法を定めただけ」という結果になる
ってのが最悪ケースとして予想されちゃうんだよな…

＞発言者が自由に決めて良い事
名前空間を自由に作れるか否か、はまた別問題だし。-戯
つまり、縛り(ってのかな、なんていえばいいのかな)が、名前じゃなく名前空間のほうに移動するのではないかな？と予想しときます。

＞何処の名前空間に属するか、に拠って答えは違ってくるでしょう
sumimさんは、例えば「Smalltalkでは○○と言いますね」のように、確かに所属の名前空間を指定しながらしゃべってたね。
では、いつぞや戯音が言ってたのはどんな名前空間での話だったのかな、と思ったわけで。--CUE

DDJ(J)？(藁 -戯




では名前空間を指定して、「HyperCard の継承は、プロトタイプベースの委譲に近い」という話を蒸し返してみましょう。プロトタイプベースでは範囲が広すぎて（あるいは曖昧すぎて）名前空間が限定できないのでプロトタイプベースの雄とも言える Self に限ります。Self では HyperCard の継承、たとえば、バックグラウンドに
on mouseUp
  set the name of the target to 'clicked'
end mouseUp
というメッセージハンドラを持たせたとき、カードボタンやカードをクリックしたときの挙動を次のように素直に表現できます。
globals _AddSlots: (| stack. bkgnd. card. crdBtn |)

stack:  (| name <- ''                                          |)
bkgnd:  (| p* = stack. name <- ''. mouseUp = (name: 'clicked') |)
card:   (| p* = bkgnd. name <- ''                              |)
crdBtn: (| p* = card.  name <- ''                              |)

crdBtn mouseUp
  -->  crdBtn の name が 'clicked' に。

card mouseUp
  -->　card の name が 'clicked' に。
もちろん、これでは継承関係を表現しただけなので、さらに、各オブジェクトのクラスである、スタックやバックグラウンド、カード、ボタンのプロトタイプを定義し、各オブジェクトの親スロット（* 付きスロット）に束縛してやらなければなりませんが、Self でなら逆に、それで終わりです。クラスベースの OOPL ではこうしたこと（GUI ウィジェットクラスのインスタンスを使って HyperCard のオブジェクト間の継承をシミュレートすること）は難しいか、難しくなくとも、トリッキーなことをしないといかんかなと思います。ということで HyperCard（の継承）は Self で比較的シンプルに表現できるから、プロトタイプベース（の委譲）に近いかも…と申し上げたわけです。--sumim

はい、クラスベースでは、シームレスにはできないですね。--CUE


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

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

This page has been visited 9545 times.