オブジェクト指向

継承について

あるふ — 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点以上を持つ人"という状態の値を含んだ定義が使えます

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

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

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

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

ダックテストを考える2

あるふ — Wed, 07 Jan 2009 03:18:00 GMT

今回は、ダックテストにおいて誰が"鴨の基準"を持つのかを考えて見ます

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

ここでは一見登場人物？は鳥だけに見えますが、違います
登場人物？は"鳥"と"鳥を見る人"ですね。今回はこれに加えて、"第三者"も加えてみます

#1.複数の人が鴨を見れば、複数の鴨の基準ができる。
鳥を見る人にとって、鴨のように見え、鴨のように泳ぎ、鴨のように鳴くものが鴨です。
しかし、第三者にとってはどうでしょう。
例えば第三者が鴨料理屋に来た客としましょう。
第三者にとっては、鴨の味がするものを鴨とみなすでしょう？

おそらく、鳥を見る人と第三者(客)では、鴨一つの単位も違うはずです。
鳥を見る人にとっての鴨は、一つとは一匹のことで、第三者にとっては一切れをさすでしょう。

何を持って鴨とするかは、鴨(らしきもの)自身を見ても全くわからない、ということです

#2.鳥を見る人は、(生物学的な)鴨じゃないものを鴨とみなすことができるし、(生物学的な)鴨を鴨でないとみなすことができる。
ダックテストにおいて、生物学的というのは単に視点の一つにすぎません
鳥を見る人が生物学的視点を採用してもいいししなくてもいいです。
実際ダックテストでは生物学的基準は含んでいませんね
精巧にできたロボット鴨なら、鳥を見る人が鴨と判断しても何の不思議もありません

鳥を見る人にとっての鴨が何かを知らない第三者にとってみれば、
ありとあらゆる全てのものが、鳥を見る人にとっての鴨となりえてしまいます。

鳥を見る人にとっての鴨の基準がわからない限り、鳥を見る人にとっての鴨を見つけることはできません。

#3.鳥を見る人は、鴨か鴨でないかの判断ができる
>それはたぶん鴨である。
とあるように、鳥を見る人は何かを鴨かどうか判断することができなければいけません
鴨自身が基準をもてない以上、鳥を見る人が鴨の基準を持つのは自明でしょう。

つまり鳥を見る人は、認識可能な全てのものを鴨の集合と鴨でない集合に分けることができます

鳥を見る人を実行ファイルとしてみたとき、
鴨オブジェクトは鳥を見る人の中に生成されます。(鴨オブジェクトを通して外部の鴨を探す)
この鴨オブジェクトの基準は誰が持つべきでしょうか。

鴨オブジェクト自身、というのが妥当な解の一つです。
(鳥を見る人の中であれば鴨オブジェクト外でもよい)

ここでいう基準とは、オブジェクトが成立するために"必須な"条件です。
オブジェクトは、必須でない特長も持つことがあります

A.ある鳥が鴨のように見えるならば、それはたぶん鴨である。鴨は鴨のように泳いだり、鴨のように鳴くことがある。
B.ある鳥が鴨のように見え、鴨のように泳ぐならば、それはたぶん鴨である。鴨は鴨のように鳴くことがある。
C.ある鳥が鴨のように見え、鴨のように鳴くならば、それはたぶん鴨である。鴨は鴨のように泳ぐことがある。
D.ある鳥が鴨のように見え、鴨のように泳ぎ、鴨のように鳴くならば、それはたぶん鴨である。

A,B,C,Dは明らかに違う基準を持った鴨ですが、インターフェースのみに注目すると、同じになってしまいます

class 鴨{
public:
    鴨のように見える();
    鴨のように泳ぐ();
    鴨のように鳴く();
};

A,B,C,Dを明確に区別するためには、インターフェースだけではなく、各インターフェースに対して
成功することが条件なのか、失敗することが条件なのか、成功/失敗は関係ないのか等の、
重み付けが必要です。

ダックテストを考える

あるふ — Fri, 26 Dec 2008 08:20:00 GMT

ダックタイピングの元になった、ダックテストを考えて見ます。

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

では、鴨、剥製の鴨を、ダックテストに通してみましょう。
鴨は、鴨のように見え、鴨のように泳ぎ、鴨のように鳴くので、鴨であると判断できます。
剥製の鴨は、鴨のように見えますが、鴨のように泳げず、鴨のように鳴かないので、鴨ではありません(もしくは、鴨であるとは限らない)

鴨である条件は、次の3つですね。
・鴨のように見える
・鴨のように泳げる
・鴨のように鳴ける

この3つの条件を全て満たす時、鴨とみなす。これがダックテストとします

"見える"はちょっとややこしいので、泳げる、鳴けるだけに注目します。
これをプログラムとして表現すると、どういった形が自然でしょうか。

#1.鴨のように泳ぐ()関数と、鴨のように鳴く()関数を持った上で、それぞれの関数に成功した時、鴨とみなす。
#2.鴨のように泳ぐ()関数と、鴨のように鳴く()関数を持つ時、鴨とみなす。

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

#1が私の解釈で、#2が検索するとよく出てくるRubyやC++によるダックタイピングの実装です(多分)。
もちろん、#2は技術的に有用ですし、ダックテストともそうは離れていません。

ただし#1,#2のどちらがダックテストの意味に近いかといえば、#1のほうが明らかに意味が近いと感じます。
何度読み返しても#1のほうが近く感じてしまいます。

例えば、鴨のように泳ぐ()関数と、鴨のように鳴く()関数を持つけれども、必ず失敗してしまうものがあったとします。
これを#2に通すと、ある鳥が鴨のように見え、鴨のように泳ぐことに失敗し、鴨のように鳴くことに失敗したなら、それはたぶん鴨である
という風に、仕様と外れたものが出来上がってしまいます。
#1では、直感どおりの判定をします

ダックテストの実装として、本当にインターフェースの保証のみでいいのか、
インターフェースの結果保証、つまり(成功するという)状態の保証までしなければいけないのか。
もしくはそれ以外なのか。

どう思いますか

無効をサポートするオブジェクト

あるふ — Tue, 23 Dec 2008 16:32:00 GMT

前項の無効をサポートするオブジェクトがどんなものかを、他の手法と比較して考えて見ます

・テストファースト
仕様の洗い出しのためにテストを作成するという意味では同じです。
どちらも動的なテストができるという意味では同じです。
クラスを作成するときに、最初にSelfTest()を作ってしまうのも同じです。

違いは、繰り返しテストを削除したことと、このテストを本番コードにも組み込むということです。
繰り返しテストを取るのか、本番コードに組み込むことによるさまざまなメリットをとるのか・・。

両方のいいとこ取りをするのがベストですかね。

・ダックタイピング
クラスの作成権、編集権が見る側に全権があるという意味で、SelfTest()オブジェクト指向とほぼ同じです。
理念は同じなのですが、現在のダックタイピングは静的に表現されることが多いです。
見る側の思惑と現実が同じかどうかの検証は動的である必要があります。

現在のダックタイピングと、SelfTest()オブジェクトは、動的か静的かが主な違いです。

・契約プログラミング
SelfTest()は、事前条件そのままという意味で同じです。
事前条件以外を使用しないという意味では違います。

現在の契約プログラミングでは、静的解決を目標にしているものが多いため、
現在の契約プログラミングとはかけ離れているかもしれません。

SelfTest()は、動的テストを重要視しています。

・ネットワーク
オブジェクト指向を、オブジェクト間、オブジェクト-リソース間の通信と考えれば、通信の手法が使えるはずです。
ネットワークの場合、切断の要因が相手にあることがあるため、
常に接続されているかどうかを確認しなければいけません。この考えはSelfTest()と同じです。

・デザインパターン
Nullオブジェクトが最も近いです。
全てのクラスがNullオブジェクトにもなれることをサポートしなければいけない、と考えるとSelfTest()と同じです

・ガード句
極めて相性がよい、というよりはオブジェクト指向をガード句に対応させたものがSelfTest()オブジェクト指向といっても過言ではないです。
どんなクラスに対しても有効なガード句を使用可能になります

・関数型
全てのクラスが"無効な状態"をサポートするため、戻り値でクラスのインスタンスを安全に返すことができます
(初期化に失敗しても例外を出さない。コード上に矛盾も起きない)。
この使い勝手が、関数型と少し似ているかもしれません

・状態遷移
必要性を感じなくなります。
SelfTest()は、全ての状態を考慮した上でどんな時にでも正しく動くことを目指すため、
特定のパターンに依存する状態遷移は必要がなくなります。

むしろ状態遷移の上位互換に近い(全てのパターンを考慮するという意味で)のですが、その分難しいともいえます

もっともイメージしやすいのはおそらく、テストファーストを本番コードに組み込んだもの、ですかね。
実際メリットの半分くらいはテストファーストと同じです。

なぜ本番コード、つまり動的にテストをしなければいけないのかは、
オブジェクト-リソース間の通信(メッセージ)と捉えているからです。
通信であれば、接続テストは必須ですよね？

オブジェクト指向の外を見てみれば、案外と普通の手法です

無効をサポートするオブジェクト手法のメリットを考えて見ます。
まず一つは、テストファーストと同様、仕様の理解を深めます。

もう一つは、プログラムの構造をシンプルにすることが可能な点です。
？？わかりませんね。

まず構造化定理を思い出してください。
全てのプログラムは順次、反復、分岐で表現できます。

このうち分岐は全て、あるオブジェクトが有効か無効かで表すことができます。
ある処理をするとき、"全ての必須のオブジェクトが有効であれば"、
順次、反復のみであらわすことが可能です。
分岐がなければ、反復は順次と読み替えても対して問題にならないでしょう。

必須のオブジェクトが一つでも無効であれば、それは制約を満たしていないので処理が中断します。

つまり、プログラムを順次と中断だけで表現することができるようになります。

分岐をなくすというよりはむしろ、初期化に持ってくるイメージに近いです。
RAII（Resource Acquisition Is Initialization リソースの確保は初期化時に)をもじって
SII(Selection Is Initialization 選択は初期化時に)とかどうでしょうか

もっともっと実装よりに言えば、全てのオブジェクトに対してガード句を使えるのが最大のメリットです
いったんこの手法に慣れてしまうと、引数のオブジェクトにガード句を使えないのが不満で不満でしょうがなくなりますｗ

int Func(Object obj){
if(int res = obj.SelfTest()){return res;}//←これ。

//何か
return 0;
}

オブジェクト指向理論04 命題

あるふ — Sat, 20 Dec 2008 00:18:00 GMT

用語の解説は一応したつもりなので、そろそろ本題に入りたいと思います。

挑戦してみたいのは、オブジェクト指向を定義からトップダウン式に展開していって、
オブジェクト指向プログラミングで使われている技術(カプセル化や継承等)につなげてみたい、ということです。

今回大量に未証明のものがありますが、それはおいおい埋めていければいいと思ってます。
若干弱いところはあるけれど、矛盾とまではいわない程度になっていると思います。

私の考えるオブジェクト指向理論の定義は次のものです。
@1.「リソース」を「オブジェクト」として「捉える」。オブジェクト指向XXでは、「オブジェクト」のみを扱う

とっちゃんさんにまとめてもらったものを利用するとこうです
「AをBの中に概念化したA'を重視する」

Aをリソースと呼び、Bを主体と呼び、A'をオブジェクトと呼ぶことにします
A、Bにはどんなものを当てはめても成り立つとします。
(B＝主体を、開発者固定にしている人は要注意です。がんがん切り替えていきます)

@1を展開していきます。

#1.捉えるということは、それを行う主体がいる
#2.捉えるというのは、主体の中にリソースをオブジェクトとして再構築すること
#3.オブジェクトは主体の中にあるので、主体がオブジェクト制御の全権を握る
#4.リソースは主体の中にあるとは限らないので、主体はリソースに対する制御権をもたない
#5.捉えるというのは正当性の基準をもつということ。
#6.オブジェクトに、そのオブジェクト及び関連付けられたリソースの正当性を保証する義務がある。
#7.オブジェクトは、主体になることができる

上記7点が全て正しいなら、ちょっとした定理が導けます。

それは、(主に＃4により)オブジェクトは常に有効でいることはできないので、
全てのオブジェクトは無効になることをサポートしなければいけない、ということです。
無効になることをサポートするというのはつまり、オブジェクトが有効かどうかを判定するメンバ関数を作る、というのと同じです。
つまり全てのクラスの基底となるObjectクラスにオブジェクト-リソース間の正当性チェック関数を持たせるべき、となります。

オブジェクト指向の定義から導かれる、Objectクラスに必要なものは、
ToString()でもなく、Serialize()でもなく、リソースまで含めた正当性判定ではないかという提案です。
(ToString()で代用できなくはないですけど)

class Object{
    //この関数が呼ばれた時点で、このクラスが正しいといえるかどうかの判定関数
    //クラスが正しくないとはどういうことか↓
    //この関数は、この関数(とOpenXX)以外の全てのメンバ関数の先頭で呼ばれ、失敗(!=0)時はそのメンバ関数が失敗する..ことになっている
    //Isで始まらないいい名前がなかったので、SelfTest()=自己診断としました
    virtual int SelfTest()=0;
};

似たような概念に、IsInvalid() があります。
ただこれは、クラス－クラスインスタンス間の正当性チェック(つまりnewした結果が失敗かどうか)を調べるというニュアンスが強いのと、(私の採用する規約だと)Isで始まる関数はboolしか返せないので、新しく名前をつけました。

重要なのは、型のチェックだけではなく、意味のチェックもするということです(意味、概念という外部のリソースとつながっているはずなので。)。
だからこの関数が調べる必要があるのは、
・外部から提示された要求仕様
・型として正しいかどうか
・メンバ変数(クラスを使う人という視点から見ればリソースにあたる)
・グローバル変数(普通はないと思いますが)
・環境変数(OSの設定、関連ファイルなど)
となります。

無効をサポートしない手法だと案外大変そうな、子供クラスで実装してみました。

class Child : public Object{
int m_age;//メンバ変数はクラスを使う人から見るとリソース。このクラスを使う人からは直接制御権がない
public:
Child() : m_age(-1){}

    //クラスは、自分が正しい状態にあるかどうかを判定できなければいけない
    //Child が、クラスとして有効であるために少なくても満たさなければいけない条件判定//制約条件
    int SelfTest(){
        if(m_age < 0){return 1;}//生まれてなければ、Childとして認めない
        if(m_age > 12){return 2;}//12歳より上なら、Childとして認めない
        return 0;
    }
};

class Child : public Object{
Human m_human;//メンバ変数はクラスを使う人から見るとリソース。このクラスを使う人からは直接制御権がない
public:
Child(){}

    //クラスは、自分が正しい状態にあるかどうかを判定できなければいけない
    //Child が、クラスとして有効であるために少なくても満たさなければいけない条件判定//制約条件
    int SelfTest(){
        if(int res = m_human.SelfTest()){return res;}//人として正しくなければ子供として正しくない

//        if(m_human.GetAge() < 0){return 1;}//生まれてなければ、Childとして認めない//←このチェックはHumanに移管
        if(m_human.GetAge() > 12){return 2;}//12歳より上なら、Childとして認めない
        return 0;
    }
};

@1.「リソース」を「オブジェクト」として「捉える」。オブジェクト指向XXでは、「オブジェクト」のみを扱う
ので、SelfTest()関数が必要
これがきれいにつながるかどうかが前半の山場です。

これが成り立てば、全てのオブジェクトは制約オブジェクトとして扱えるようになります。
そうなれば、それを使って継承等の仕組みを説明できる・・ような気がしますよね？

オブジェクト指向理論？03 インスタンスとリソース

あるふ — Thu, 18 Dec 2008 01:55:00 GMT

私-犬が対話する時、オブジェクト指向プログラミング用語の"オブジェクト"は、

"私"の中、つまり"私の妄想の中の犬"にあたります。

イメージしにくいので、比較表を作ってみました。

	私の妄想の中の犬	現実の犬	クラス/インスタンスの犬	リソースとしての犬 (例えばファイル)
作成	私の意思により可能	現実のルールに従う	ソフトウエアの意思により可能	外のルール(OS等)に従う。(依頼することは可能)
複製	私の意思により可能	現実的には不可能	ソフトウエアの意思により可能	外のルール(OS等)に従う
消去	私の意思により可能	現実のルールに従う	ソフトウエアの意思により可能	外のルール(OS等)に従う
カプセル化	可能	一切しない(見る側の能力に依存)、	可能	一切しない(見る側の能力に依存)
継承	可能	不可	可能	不可
正しさ	私にとっての正しさの基準を全て満たす	見る側に依存	ソフトウエアにとっての正しさの基準を全て満たす	見る側に依存
非現実的なもの	作ることが可能、	現実のルールに従うものしかない	作ることが可能	現実のルールに従うものしかない

下記二つの組み合わせは、全く同じといっていいほどよく似た特徴を持ちます。

私の妄想の中の犬=クラス/インスタンスの犬

現実の犬=リソースとしての犬

それ以外の組み合わせで "同じ"であるというのは無理があると思うのですが、どうでしょうか。

オブジェクト指向プログラミングの適用範囲は以外に狭くて(この例では)実行ファイルの中だけであることと、

一般用語のモノとオブジェクト指向用語のオブジェクトは別物であり、混同してはいけないということを示しているだけで、

別段変ではない、はずです。

テーマについて。

「オブジェクト指向」＝「オブジェクトを指向することにより得られる理論、オブジェクト指向プログラムの正しさの拠りどころとなる理論の総称」

つまり名詞で使ったときには、暗黙的に"理論"が足されると思っていました。

とりあえずオブジェクト指向理論としてみましたが、意味的に大丈夫でしょうか。全く自信がないです

"オブジェクト指向する"は日本語としてとてもわかりにくいので、

私は日本語の資料によくある@1をオブジェクト指向XX？の定義としています。
@1.「モノ」を「オブジェクト」として「捉える」。オブジェクト指向XXでは、「オブジェクト」のみを扱う
@2.人の認知はオブジェクト指向XXの仕組みと同じ
(@3.オブジェクト指向プログラミング)

基本的には、@1だけを使用して論理展開した理論が、オブジェクト指向プログラミングの基盤となる理論であると思います。
実際には@2を根拠として使用しても許されるはず。

万が一@1がおかしかった場合は、全てがおかしいので早めに教えてもらえると大変助かります。

オブジェクト指向02 定義2

あるふ — Tue, 16 Dec 2008 21:48:00 GMT

前回の私の質問の、私なりの解釈です。

私が犬に鳴けといったら、犬がワンと鳴いた。

これをオブジェクト指向(*1)であらわすとしたら、何になるのかという質問でした。

ズバリ結論からいきましょう。

・クラス＝私の頭の中の像

・クラスのインスタンス＝私の頭の中の像

・オブジェクト＝クラスのインスタンス

・開発者＝該当無し(あえていうなら神？/世界？)

・プログラム=実行ファイル=私

・設計図＝該当無し(誰も犬を作ったりはしていない)

"犬"に値するものはリストにないです。

私はリソースと呼んでることが多いです。

実際に現実のプログラムを見た時、私＝実行ファイルとすれば、

クラスとクラスのインスタンスは私＝実行ファイルの中にあるという解釈以外ありえないと思います。

犬ではわかりにくいと思うので、もっとよくある例にしてみます。

例えばファイル。

ファイルは実行ファイルの外にありますが、アクセスする時には実行ファイルの中にクラス及びクラスのインスタンスを作成します。

例えばユーザ。

ユーザは、実行ファイルどころかPCの外にいますが、操作する時には実行ファイルの中にクラス及びクラスのインスタンスを作成します。

私-犬の関係の時、私のなかに本当にクラス/クラスインスタンスができてるかも考えて見ます。

人は、自分の中で世界を再構築し、その世界を通して行動しています。

(単に目や耳をとおしてるというだけでもここでは十分かもしれませんがもう一歩)

例えば犬がワンと鳴く時、その音は口から出ていると思いますよね。

でも音だけ聞いただけだと、多分正確な位置はわからないでしょう。

視覚情報と、聴覚情報が組み合わさって、つまり脳内で再構築するおかげで

正しく口の位置から声が出ていると判断できるわけです。

まとめます。

クラス/クラスのインスタンスと、ここでいう犬(つまりリソース？）は、全く違うものであるということです。

そしてそれはつまり、クラス/クラスのインスタンスがオブジェクトであれば、

犬(つまりリソース？）は

オブジェクトではない

ということです。