東方算程譚

Oriental Code Talk ── επιστημηが与太をこく、弾幕とは無縁のシロモノ。

目次

Blog 利用状況

ニュース

著作とお薦めの品々は

著作とお薦めの品々は
東方熱帯林へ。

あわせて読みたい

わんくま

  1. 東京勉強会#2
    C++/CLI カクテル・レシピ
  2. 東京勉強会#3
    template vs. generics
  3. 大阪勉強会#6
    C++むかしばなし
  4. 東京勉強会#7
    C++むかしばなし
  5. 東京勉強会#8
    STL/CLRによるGeneric Programming
  6. TechEd 2007 @YOKOHAMA
    C++・C++/CLI・C# 適材適所
  7. 東京勉強会#14
    Making of BOF
  8. 東京勉強会#15
    状態遷移
  9. 名古屋勉強会#2
    WinUnit - お気楽お手軽UnitTest

CodeZine

  1. Cで実現する「ぷちオブジェクト指向」
  2. CUnitによるテスト駆動開発
  3. SQLiteで組み込みDB体験(2007年版)
  4. C++/CLIによるCライブラリの.NET化
  5. C# 1.1からC# 3.0まで~言語仕様の進化
  6. BoostでC++0xのライブラリ「TR1」を先取りしよう (1)
  7. BoostでC++0xのライブラリ「TR1」を先取りしよう (2)
  8. BoostでC++0xのライブラリ「TR1」を先取りしよう (3)
  9. BoostでC++0xのライブラリ「TR1」を先取りしよう (4)
  10. BoostでC++0xのライブラリ「TR1」を先取りしよう (5)
  11. C/C++に対応した、もうひとつのUnitTestFramework ─ WinUnit
  12. SQLiteで"おこづかいちょう"
  13. STL/CLRツアーガイド
  14. マージ・ソート : 巨大データのソート法
  15. ヒープソートのアルゴリズム
  16. C++0xの新機能「ラムダ式」を次期Visual Studioでいち早く試す
  17. .NETでマンデルブロ集合を描く
  18. .NETでマンデルブロ集合を描く(後日談)
  19. C++/CLI : とある文字列の相互変換(コンバージョン)
  20. インテルTBBによる選択ソートの高速化
  21. インテルTBB3.0 によるパイプライン処理
  22. Visual C++ 2010に追加されたSTLアルゴリズム
  23. Visual C++ 2010に追加されたSTLコンテナ「forward_list」
  24. shared_ptrによるObserverパターンの実装
  25. .NETでマンデルブロ集合を描く(番外編) ── OpenCLで超並列コンピューティング
  26. StateパターンでCSVを読む
  27. 状態遷移表からStateパターンを自動生成する
  28. 「ソートも、サーチも、あるんだよ」~標準C++ライブラリにみるアルゴリズムの面白さ
  29. インテルTBBの同期メカニズム
  30. なぜsetを使っちゃいけないの?
  31. WPFアプリケーションで腕試し ~C++でもWPFアプリを
  32. C++11 : スレッド・ライブラリひとめぐり
  33. Google製のC++ Unit Test Framework「Google Test」を使ってみる
  34. メールでデータベースを更新するココロミ
  35. Visitorパターンで遊んでみたよ
  36. Collection 2題:「WPFにバインドできる辞書」と「重複を許す検索set」
  37. Visual C++ 2012:stateless-lambdaとSQLiteのぷち拡張
  38. 「Visual C++ Compiler November 2012 CTP」で追加された6つの新機能

@IT

  1. Vista時代のVisual C++の流儀(前編)Vista到来。既存C/C++資産の.NET化を始めよう!
  2. Vista時代のVisual C++の流儀(中編)MFCから.NETへの実践的移行計画
  3. Vista時代のVisual C++の流儀(後編) STL/CLRによるDocument/Viewアーキテクチャ
  4. C++開発者のための単体テスト入門 第1回 C++開発者の皆さん。テスト、ちゃんとしていますか?
  5. C++開発者のための単体テスト入門 第2回 C++アプリケーションの効率的なテスト手法(CppUnit編)
  6. C++開発者のための単体テスト入門 第3回 C++アプリケーションの効率的なテスト手法(NUnit編)

AWARDS


Microsoft MVP
for Visual Developer - Visual C++


Wankuma MVP
for いぢわる C++


Nyantora MVP
for こくまろ中国茶

Xbox

Links

記事カテゴリ

書庫

日記カテゴリ

神の存在

ネタ元 → オブジェクト指向 01 定義

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

これをオブジェクト指向しろって?
まず私と犬はクラスかインスタンスか。

ワンと鳴くのは犬クラスのメソッドがそうさせるのか、
私が鳴けといった犬インスタンスがたまたまワンと鳴いたのか。
# 別の犬インスタンスならキャンと鳴くかも。あるいは鳴けないかも。

「犬」は四つ足でワンとかキャンとか鳴く動物の総称だからクラスっぽい。
「犬に鳴けという」は犬クラスのクラスメソッド「鳴く」を呼ぶのか。
だとすると犬の存在なしに鳴けることになる。まさかぁ。

ならばここでの犬は犬クラスのいちインスタンスなんだろう。
私は人クラスのインスタンスなんだろうか。

interface 鳴くもの {
  void 鳴く();
}

class 犬 : 鳴くもの {
  public void 鳴く() { ワン; }
}

class 人 {
  public void 鳴けという(鳴くもの なにか) { なにか.鳴く(); }
}

...さて、登場人物が足りない。
私に鳴けといわせたのは誰だ? 神か?
神に「私に鳴けといわせる」のを指示したのは誰だ? 神の神か?
かくして無限連鎖に陥る。

(最初の)マッチに火をつけた"それ"をオブジェクトにできない。
オブジェクトはメソッドが呼ばれぬ限り仕事をしないはずだし、
そもそも"それ"を召喚した"誰か"が必要だから。
その誰かが存在するなら、"それ"はマッチに火をつけた張本人じゃない。



投稿日時 : 2008年12月19日 11:40

コメントを追加

# re: 神の存在 2008/12/19 12:13 インドリ

そうなんですよね♪
それでオブジェクト指向は三位一体なんだよね♪
結局のところ、オブジェクト指向は抽象化思考技法なんで現実とは等価にならないって事ピヨ♪
情報粒度と抽象度を決めないと、epiさんが指摘しているように無限ループになるだけなんだよね♪

# re: 神の存在 2008/12/19 12:27 774RR

神は存在するぢゃないですか。ユーザって神が。

# re: 神の存在 2008/12/19 12:42 biac

> interface 鳴くもの {

Object-Oriented Program の世界の話ですね、 わかります。

# επιさんが言わんとすることがわかるわけじゃなくて、 何について議論しているのかが分かる、 ってことね f(^^;

> 神は存在するぢゃないですか。ユーザって神が。

そしてユーザもまたオブエジェクトですから ( …と、 わざと Object-Oriented Program の世界からはみ出して混乱させる f(^^; )、 そのユーザをそうさせたモノがいるはずで…
…最後は、 この宇宙に最初の一撃を与えたナニカに行きつくのです f(^^;

# re: 神の存在 2008/12/19 12:55 επιστημη

> 現実とは等価にならないって事
いや、僕は現実の話なんかしてねぇです。

# re: 神の存在 2008/12/19 13:01 インドリ

ボクはてっきり、「私が犬に鳴けといったら、犬がワンと鳴いた。 」の問題を解くには、どこかで開発上の妥協しないとならないと説いているのだと思いました。

# re: 神の存在 2008/12/19 13:16 とりこびと

私に鳴けといわせたのは私。
あ、私は私とはちがいます。


とかわけ分からない書き方をしてみるw

# re: 神の存在 2008/12/19 13:28 ぱると

とてつもなく規模が大きくなってしまうけど、
「世界」という1つの大きな実行ファイルがあって(ずっと実行中)
その中で「私」インスタンスがNew(誕生)したときから
インスタンス自身でタイマー監視しておいて
私が「言葉を発する」という条件(意思)を満たした時に
「鳴けという」メソッドを呼び出しているんじゃないかと思いました。←「私に鳴けといわせたのは私。」と同意見です

「意思」はどこから設定されるのかはわかりません…わかったら意思を持った人工知能作れそうだ。
「世界」を実行したのが誰かわかる人はビックバンの原理を理解した人かと。

うーん、これ以上深く入ると宗教の域になりそうだ(汗
無宗教の自分にはこれ以上つっこめません…。

# re: 神の存在 2008/12/19 13:30 επιστημη

> どこかで開発上の妥協しないとならない

それはそのとーりなんですが、開発を伴わなくたって
「誰がマッチに火をつけた?」問題はつきまとうんぢゃねーかと。

実際ここらへんがうまく説明できんくて困ってるとこなのですわ。
オブジェクトとそれらのインタラクションをきっちり書いても
開始点が見当たらないのでオブジェクト指向に慣れてないヒトに(慣れたヒトでも)"きょとん"とされちゃうです。

マッチに火をつけた張本人をオブジェクトとすると無限連鎖に陥るので、
ここんとこだけはオブジェクトモデルに描きづらい。
描かないと開始点が見当たらなくなる...

# re: 神の存在 2008/12/19 15:19 biac

> 実際ここらへんがうまく説明できんくて困ってるとこなのですわ。

επιさん、 純粋だから。

不純な私は、 OOP ったってどうせ実行時には CPU のインストラクションセットの羅列に化けるんだから、 ちょろっと手続き指向が混ざるくらいは、 気にしない気にしない f(^^;;;
# そんな態度では OOP は進化しないっすね、 ごめんなさい m(_`_)m

# re: 神の存在 2008/12/19 15:30 n

私に鳴けと言わせたのはコンピュータ

コンピュータを操作してるのは私

# re: 神の存在 2008/12/19 15:56 επιστημη

> ちょろっと手続き指向が混ざるくらいは、 気にしない気にしない f(^^;;;

いやま「マッチは別枠」と割り切ればそれでいい話ではあるんす。
すべてをクラス/オブジェクトで表現しようとすると穴が空くってことで。

> 私に鳴けと言わせたのはコンピュータ

それをモデルに組み入れると無限連鎖を避けられなくなるよ、てゆーてます。

# re: 神の存在 2008/12/19 16:05 インドリ

面白い題材ピヨッ♪
マッチに火をつけたをよく考えると、人間インスタンスがマッチに火をつけるメソッドを実行した際に、何らかのイベントが発生してその結果火がついたことになるピヨ♪
で、人間インスタンスがなんでマッチに火をつけようと思ったかは、自己進化インスタンスの計算結果だと思うピヨ♪
きっと、周りのインスタンス状態の算出結果から、人間の機能サブオブジェクトが「火をつける必要がある」との算出結果をメッセージで送り、そのメッセージがしかるべきサブオブジェクトに伝わった際に、インスタンスが自己でメソッドを実行すると見たピヨ。
名づけて、アクティブインスタンス、ピヨ! byメタプログラミングの一種

# re: 神の存在 2008/12/19 16:06 インドリ

このボクの理論では、世界はSamlltalk状態になっていて、インスタンスは自分でメソッドを呼ぶ状態ピヨ♪

# re: 神の存在 2008/12/19 16:10 インドリ

ちなみに、この世界では型がメタプログラミングで自動的に生成されるピヨ。
だから、神様にも何で人間と言う型が出来たかわかない状態なんだw
その神様はきっと、自分が生まれた理由を知るために、Smalltalk世界を観察しているピヨ♪

# re: 神の存在 2008/12/19 16:12 よねけん

モデルは誰かの視点で描かれます。
そのモデルが存在するということはそのモデルの外側に誰かがいます。
モデルの外側にいるのでそのモデルで表現する対象ではありません。
ってことですよね。

# re: 神の存在 2008/12/19 16:16 インドリ

で、その最終的な神様が生まれた要因は、結局の所、バイナリが偶然そうなっただけだと思うピヨ♪

# re: 神の存在 2008/12/19 16:18 インドリ

>モデルは誰かの視点で描かれます。

いえ、そうじゃないピヨ♪
Smalltalkのような自己生成型オブジェクト環境は自然発生したもので、各々のインスタンスが自分で(アクティブに)動いて、世界を観察している状態ピヨ♪
結局のところ、ボクは偶然の産物で土壌が出来て、その上に出来たインスタンスが悩んでいるだけだと思うんだ。

# re: 神の存在 2008/12/19 16:20 インドリ

つまり、世界=最高神というオブジェクトだと言う事ピヨ♪

# re: 神の存在 2008/12/19 16:25 インドリ

おっと失礼。
普通はよねけんさんの意見で終わるピヨ。
今回はちょっと冒険してみたピヨ♪

# re: 神の存在 2008/12/19 16:50 επιστημη

> モデルの外側にいるのでそのモデルで表現する対象ではありません。

そゆことになりますか。
しかしながら現にマッチに火をつけたmain()は実装せにゃならんです。
モデル中に表現できんにもかかわらず。

# コメントは歓迎だが連投するくらいならまとめてから書いてくれ。荒らされてるみたいだ > インドリ

# re: 神の存在 2008/12/19 16:55 インドリ

>コメントは歓迎だが連投するくらいならまとめてから書いてくれ。荒らされてるみたいだ

済みません。興奮してしまいました。
まとめて自分のブログに書きました。

# re: 神の存在 2008/12/19 17:09 よねけん

> しかしながら現にマッチに火をつけたmain()は実装せにゃならんです。
> モデル中に表現できんにもかかわらず。

モデルが閉じた世界だとすると
外側からそこにアクセスするには、
窓なり扉なりがあると思うのですが、
その窓なり扉なりが、UIやらmain()やらになるんじゃないでしょうか。
#これはどこかの偉い人が言ってた話でなくて、
#今、私が考えたこじつけですけどね。

# re: 神の存在 2008/12/19 17:19 επιστημη

うん、main()が内部世界を構築し、内と外とのメッセージ交換窓を開いて、メッセージループをくるくる回すわけやね。
そんな大事な使命を負いながらモデルには現れないのが不憫で不憫で ^^;

そんな大事な使命を負うならクラスに格上げし、main()ではそいつに火をつける:

int main() {
 World world;
 world.run(); // 光あれ
}

ぶっちゃけ
Application.Run(new Form1());
ですな ^^;

# それでもやはり main()はモデルに現れん、と。

# re: 神の存在 2008/12/19 17:58 みきぬ

> 私に鳴けといわせたのは誰だ?
このへん別の考え方をすると、犬や人はなぜ生きているのか? ってーことにもなるのかも。


> 神に「私に鳴けといわせる」のを指示したのは誰だ?
きっと界お(殴

# re: 神の存在 2008/12/19 18:11 επιστημη

ちなみにウチの魔王サマは二度目の世界征服ちう。
前回は虫も殺さぬ(散々殺したけど)善人魔王サマ。
目下非道の極みを登りつめた極悪魔王サマ街道驀進中であります。
「いえす・ますたぁー!」

# re: 神の存在 2008/12/19 18:53 インドリ

やっぱりモデルは抽象度と情報粒度の前提があるんだよね♪
抽象度を下げると、結局はmainメソッドを呼ぶコンパイラの生成コードとか、その実行を行うOSのローダとか・・・モデルに書かく必要が出てくるもんね♪
でも、モデルに書けないのじゃなくて、普通の設計者が書かないだけだと思うな。
書こうと思えば、OSの設計から全てかけるもの。

# 犬は自分の意思で鳴くのでは? 2008/12/20 0:23 Ognacの雑感

犬は自分の意思で鳴くのでは?

# re: 神の存在 2008/12/20 0:37 Jitta

> 開始点が見当たらないので
今上げたエントリで、「舞台」としてみました。あらかじめ台本が配られ、演じることが決められています。舞台が始まると、決められた時間にことが起こります。
命じたのは台本を書いた人や監督という、舞台には出てこない人です。つまり、開発者。

ってことでどうでしょう?

タイトル
名前
URL
コメント