Nm

継承について

あるふ — Thu, 12 Mar 2009 02:25:00 GMT

継承(+委譲)について考えていきます

今回は、継承についての最初ということで、継承について現在私が考えているもの、これから求めていこうと思うものをざっくり出します
各項目の詳細な説明は次回以降ということにします。
(一応最低限の情報は載せるので実際にやるかどうかは気分しだいということで)
最近数学を見だしたばかりなので、数学用語等間違いがあれば主旨を変えない程度に変更する可能性は高いです

#1, 単一継承は多重継承の一形態ではないか
class C : public A, public B{}; //AとBを多重継承したC
class C : public A{}; //Aと無名の型を多重継承したC = 単一継承

//class C : public A, public 無名の型{/*中身は空*/}; //単一継承は←と同じと考える。Cは何も継承しなければ空集合とする

#2, 継承に使える要素
継承という仕組みに使えるのは集合のみだとします。(なぜかは、まだよくわからない)
これ以降、集合の特性を使います。
最も重要な特性は、"全ての集合は、ある条件を持つ"ということです
この条件のことを以後制約と呼びます

#3, 階層構造<-->制約の変形
継承は、階層構造を持ちますが、これがどうにも扱いにくかったので制約の形に置き換えます
(相対パス(階層)<-->絶対パス(制約)のイメージ。継承で扱う階層は全て包含だとします)

ここに、ある集合の包含階層 A->B->C があるとします

これを制約表記(私の独自用語：おそらく何か専門用語があるはず)に置き換えます。(単に積集合を適用します)
$A ： Aの制約を持つ = A = $Aの制約
$B ： Aの制約とBの制約を持つ = A かつ B = $Bの制約
$C ： Aの制約とBの制約とCの制約を持つ = A かつ B かつ C = $Cの制約

包含階層のAとCは階層が違うため演算ができません。
A->B->CにおけるCの制約は(A かつ B かつ C)であって、Cの制約は必要条件に過ぎないため、
Cの制約だけではCであることを表せず、AとCを同一の空間で扱うことができません

$A,$B,$Cなら、階層を気にせず扱うことができます

#4, Aであること及び、AかつBをオブジェクト指向に適用してみる
@1, Aならば、A'という必須なインターフェースを持つ
@2, Bならば、B'という必須なインターフェースを持つ

@3, Aならば、A''という(インターフェース以外の全ての)制約を満たす
@4, Bならば、B''という(インターフェース以外の全ての)制約を満たす

@1,@2,@3,@4が真のとき、
@5(AかつB)ならば (A'のインターフェースを持つかつ B'のインターフェースをもつ)が真
@6(AかつB)ならば (A''の制約を満たすかつ B''の制約を満たす)が真
ここまではOKなのですが、次はどうでしょうか。

@7(A'のインターフェースを持つかつ B'のインターフェースをもつ)ならば(AかつB) が真？？？
逆は必ずしも真ならずであり、@7は必ずしも真ではありません

@7は、@1,@2があってもなくても関係ないとき、つまりA'',B''が恒真のときのみ真です

@1も@3もAの必要条件です。
わざわざ分けたのは、プログラム言語がそうしていることが多いというだけです。
@1と@3をあわせると、"Aであるための全ての制約"と呼べます。
要はAであるための必要十分条件です

#5, 項目#4の、@1と@3の違い
インターフェースは、集合を分割する基準を持つことを表すことはできますが
分割された集合を選択することができません

例えば"赤色のもの"という型を作りたい時
X:"赤色かどうかという関数を持つ集合"と、Y:"赤色であるという集合"は同じ集合ではありません
X=赤い集合+赤くない集合 (赤色が何かということは知っている)
Y=赤い集合 (赤色が何かということは知っている)

制約という表現で言い換えると、
X=赤色かどうかという関数を持つという制約という一つの制約を持つ集合
Y=赤色かどうかという関数を持つという制約と、赤色であるという制約という二つの制約を持つ集合

"赤色のもの"という型を作りたい時は、当然(XかYかでいえば)Yでなければいけません。

#6, AかつBとは、実装多重継承である
AとBが完全に別な時(独立している時？)、AかつBは実装多重継承を表します
しかし、現在のオブジェクト指向による継承の仕組みでは、インターフェースによる制約にしか対応していません。
だからインターフェース以外に制約があった時、現在のオブジェクト指向では実装多重継承は、
継承により必要な制約を引き継げないので、うまくいかないことが多いという予測が立ちます

項目#1より、単一継承は多重継承の特殊な形と考えた時、この問題は単一継承でも起こるはずです。

#7, インターフェース継承とは、AもしくはBの(IF以外の制約が)恒真のときのAかつBである
(c.制約 = (A.制約 && true))
オブジェクト指向言語によるインターフェースは実装のない関数を指します。
インターフェース以外の制約が恒真であることは、この実装のない関数、インターフェース継承で表すことができます

現在のオブジェクト指向ではこの"片側が恒真"という場合に必要なものを全てもっているので、
インターフェース継承はうまくいくことが多いと予測できます

#8, Aの全ての制約とBの全ての制約が同じ時、つまりAかつAの時はどうか
俗にis-aと呼ばれているものです。リスコフの置換原則も同じですかね？
現在のオブジェクト指向ではインターフェースは全て引き継がれるので、
おそらくインターフェース以外の全ての制約が同じであることをさしているのだと思います

Aが真のとき、AかつAは真になりますから、理屈としては正しいです

問題は、現在のオブジェクト指向(だけ)でこれを守るのは現実的に不可能であるということです
AとBがずれた時に検知する仕組みがないこと、そもそもAであることを示せないことが原因です

#9, Aの必要十分条件
オブジェクト指向では、Aの制約を表すことができません
ではここで仮に、Aという集合の制約をXとおいてみます

制約に含まれるものは全て、条件を満たすか満たさないかの2値、boolで表すことができます
条件がどれだけあっても、それらを全て積で重ね合わせれば、たった一つのboolとして表すことができます

Aという集合の制約Xは、一つのbool変数としておくことができます
全ての(少なくとも継承の可能な)要素は、一つのbool変数を持たなければいけません

bool変数とboolを返す関数は(多分数学的に)同等なので、boolを返す関数をおきましょう

オブジェクトがこの特殊な意味を持った boolを返す関数を含むのであれば、
インターフェースだけで "あるオブジェクトである"ということを示すことができます

Aであることが表すことができるようになれば、AかつBを表すことができるようになります
つまり、この仕組みを使えば、実装継承が可能になるはずです

うーーん。
まあそもそも全ての集合は、集合の条件をもつので、クラスを集合としておくのであれば、
全てのクラスはクラス(集合)の条件を表すboolを返す関数(もしくは同等の何か)を持たなければいけない、とするだけでも十分なのかもしれません。

視点と命題

あるふ — Mon, 16 Feb 2009 03:27:00 GMT

ずっとblogについて考えつつネットを見ていたら、ハッと閃きました

今まで定義とかオブジェクトと私が呼んでいたものは、数学用語の「命題」でした
wiki等の説明を読む限り、私のイメージと完全に一致します

ソフトウエア、もしくは任意のスコープを一つの公理系としたとき
そのスコープ内にあるものは全て命題として扱うことができます

wikiの内容を超えるところがあるので、もう少し詳細をだします。
そもそも命題とは何かというと、真偽値をもつ明確な文です。

・私の身長は160cm以上である
これは意味的に不明瞭なところがみあたらないので命題

・彼は偉人である
これは偉人の定義が不明瞭なので命題ではない

さて。
ではここで、ほとんど全ての文を命題に変えてしまえる魔法のようなテクニックを紹介しましょう。
それは、「全ての単語の前に<<○○にとっての>>と付け加える」ことです。(より正確に言うなら、それを行った全ての用語の定義も必要。そのスコープ内で一つの用語には一つの定義しかないという前提も必要)

先ほど命題ではない例として出した「彼は偉人である」を命題に変えてみましょう
そのためには誰かが必要なので、A君を出してみます。
・A君にとっての彼はA君にとっての偉人である。
これで命題になりました。

他にもいくつか作ってみましょうか。
「富士山は美しい」は命題ではないが、「A君にとっての富士山はA君にとっての美しいです」は、命題です。
「5000は大きい」は命題ではないが、「A君にとっての5000はA君にとっての大きいです」は命題です

この<<○○にとっての>>と付け加えた上で、その用語を定義する技法を
抽象化と呼びます。・・呼べるはずです。

ありとあらゆる全ての抽象化でこの技法が使われています
映画しかり、小説しかり。人もそうですね。

そして数学でもそうです。

数学では、実は必ず公理系を選択しなければいけません。公理系が選択されていなければ全ての文は命題となりません。
ある公理系Cでは、AはBである。
これは命題です。

(公理系が不明な時、) AはBである。
このように、公理系を選択しない文は、命題ではありません

ソフトウエアを独自の公理系と考えます。公理系という言葉になじみがあまりないので、以後視点と呼びます
ソフトウエア内部にあるものはすべて"そのソフトウエアにとっての○○"です
そのソフトウエアにとっての○○の定義は、プログラムのソースとして全て存在するはずです
だからソフトウエアは、命題という形で全てをあらわすことが可能だと思います
(もし一部例外が出たばあいは、命題として扱えるものだけを対象とする、と変更するかもしれません。まだそこまで考えが固まっていません)

ダックテストを考える3 オブジェクトの正当性

あるふ — Tue, 20 Jan 2009 01:42:00 GMT

もう一度ダックテストでいきます

用語の説明は次のものです
ある鳥が鴨のように見え、鴨のように泳ぎ、鴨のように鳴くならば、それはたぶん鴨である。

この例では、鳥を見ている人が、"鴨のように泳ぐことができる"、"鴨のように鳴くことができる"
という少なくとも2つ以上の条件が同時に成立することを定義としていることがわかります

複数の条件が同時に成立するかどうかを判定することは、多分原理的？(もしくは計測的？現実的？)に不可能です。
同時に観測することが不可能である点と、同時に判定することが不可能であるという点において。

これを解決する方法は今のところ一つしか思いつきません
ある条件を確認した後、その結果がある期間において変化しないと決め付けてしまうという方法です。
こうすれば、どれだけ条件がたくさんあっても、ある期間内であれば判定が可能になります

期間は、時間つまりタイムアウト付きとしてもいいし、何かのトリガーで寿命としてもいいですね

そういったものを何というかというと・・要は変数/状態です
複数の条件を同時に満たすことが求められる時、変数が必要になります
条件は全て、満たすか満たさないかの2値、つまりbool変数として表すことができます

オブジェクトの条件、ダックテストで使用した
XXができることを条件とする、もしくはXXができないことを条件とする、
といった条件もbool値とその評価の組み合わせとしてとれます

オブジェクトが正しい状態というのがどういう状態かというのを表明できます
オブジェクトは正しい状態と正しくない状態の2値、つまりbool値となれるので、
オブジェクトが他のオブジェクトの条件の一つとなることも可能になります

総括すると、ダックテストはある種の状態制御を含む概念である、ということです
オブジェクトの正当性とはつまり状態の値かつ定義です。
正しい状態の値(の範囲)を定義に含むことをサポートしなければいけません

状態の値を含んだ定義というのは実に普通のことです

ある会社の採用条件として、TOEIC600点以上の人が必要だとしましょう
ダックタイピングでは"TOEICの点を持つかもしれない人"程度の定義でしか表現できません
ダックテストでは"TOEIC600点以上を持つ人"という状態の値を含んだ定義が使えます

状態の値を含んだ定義の例はいくらでもあげることができます
元気な犬/病気の犬 (健康というパラメータの値)
黒色のもの/灰色のもの (明度という状態の値)
きれいな机/汚い机 (整頓度？)

例えばあなたは、"きれいな机"を見つけることができます
"机"をみつけてきれいかどうかを見るのではなく、"きれいな机"を直接見つけられるはずです
それはあなたが、あなたの頭の中で状態の値を含んだ定義を作成できるからです

状態の値を定義に含むことを、人間(の認知)はサポートしています
抽象化もサポートしています
ダックテストもサポートしています
実はソフトウエア(=実行ファイル=プログラム)もサポートしています

それらから作られたはずの、今のオブジェクト指向プログラミング(の解説)と今のダックタイピングはサポートしていません
これは問題であり、状態の値を定義に含むことをサポートすべきだと私は考えます