> C言語で実装している例が、他の言語では数行で実現できているのを見るにつけ
> いいなぁって指くわえちゃいます。
そうですね。逆にC言語でサクッと実装しちゃうのも凄いなと思ったり。
（私はC frontを使ったことがないのでそれとの比較も見てみたいなぁ。）
> うーん。ここで言ってるコマンドってどういうものを指してるんでしょうか?
> 私などはコマンドって言うとcp,mv,rm,grep,find,ps,less,sed,awk,...などが
> 思いついてしまうので「えっ、どこのどのへんが?」って思っちゃいましたが。
> processを分離して、processに対して、特定のcommandを送る(kill,truss)とかは
> ある意味、object(process)にmessege(command)を送っている感覚に近いですが
> でも、継承もしない(できない)し、ちょっと違うような気もしますが?
確かに。かなり世迷言チックですね・・・(^^;
コマンドというのはそれで合っています。
topやらsarなんかで状況を打診したりとか、
パイプでつないでコマンド間で連携を取るのがメッセージっぽいかなって思いました。
（まぁ、パイプはストリーム経由でつないでいるわけですが、
ストリームがメッセージキューのイメージというか。）
継承はできませんが、Bシェル系である機能を持ったスクリプト組んで、
下位のスクリプトから「.」で読み込んで無理やりコマンドやら関数のオーバーライトくらいできるかも！？
それはさておき、もうちょっとオブジェクト指向を勉強してきます。
でも才能無しかも・・・(;_;)
> ということで、後は本編の続きが出るまで引っ込みます。
すみません、この連休は温泉行ってのんびりしてきますので、まだちょっと
続きが出せそうにないです。(_o_)
まあ内容的にはここで既に出ている話と同じようなものになりそうなんですが…
>
> そういう面もあるかとは思います。某(非公開の)メーリングリストでも、
> 同様の指摘を受けました。真っ先にポリモルフィズムを教えるのがよいのでは
> ないかと。
>
> このへんは人それぞれなんでしょうね。
> 逆に、いきなり知らない概念(というか知らない用語)が山ほど出てくると
> 拒否反応を示す人もいるはずです。
それは同意します。オブジェクト指向でも用語の氾濫は確かに理解を妨げていると
思います。（「新しい概念」と「新しい用語」の間には微妙にずれがあるのですが、
そこはまあいいことにしましょう。）
> しかし、どちらの人を想定するにせよ、「インスタンス」がわからない限り
> ポリモルフィズムがわかることはあり得ないと思うんですよ。
> そして実は初学者にはここが一番難しい。いったん分かってしまった人は
> そんなのは当たり前だと思っているけれど、実は初学者には難しい。
> 異論もあるかもしれませんが、私はそう思っています。
これも異論ありません。
私は、
> 「マルチプルインスタンス」が重要だと書いているのは、そういうことです。
に対して異議を差し挟んではいないつもりです。
ということで、後は本編の続きが出るまで引っ込みます。
> 私はどちらかと言うと、いままで知らなかった概念を最初に出してくれた方が新しい言語なり
> 開発環境に入りやすい方なんです。なんらかの驚きがないと、その先に進む気が失せるというか(^^;
そういう面もあるかとは思います。某(非公開の)メーリングリストでも、
同様の指摘を受けました。真っ先にポリモルフィズムを教えるのがよいのでは
ないかと。
このへんは人それぞれなんでしょうね。
逆に、いきなり知らない概念(というか知らない用語)が山ほど出てくると
拒否反応を示す人もいるはずです。
しかし、どちらの人を想定するにせよ、「インスタンス」がわからない限り
ポリモルフィズムがわかることはあり得ないと思うんですよ。
そして実は初学者にはここが一番難しい。いったん分かってしまった人は
そんなのは当たり前だと思っているけれど、実は初学者には難しい。
異論もあるかもしれませんが、私はそう思っています。
新人向けのJava研修の講師をやったとき、
http://member.nifty.ne.jp/maebashi/nazojava/xdraw/index.html
にある「X-Draw」を作ってもらったことがあります。
で、とある新人君は、(AWTの)Canvasに線を引きたい、という時、
その場でCanvasをnewしてそのCanvasに線を引いてくれました。
もちろんそのCanvasと、実際に画面に貼られているCanvasは違うCanvasですから、
画面に線は表示されず、彼は悩んでいたわけですが。
「分かっている人」からすれば、「んなアホな」と思えるようなポカでしょう。
実際私の同僚も「んなアホな」というようなことを言っていました。
しかし、同様のポカを、複数の新人君が複数の箇所で犯していたのです。
サンプル数は少ないですが、「複数の新人君」は過半数です。
また、大昔、Cでちょっとしたカスタマイズ用プログラミング言語の
インタプリタを(仕事で)書いたとき、グローバル変数の名前空間を分けたい
などの理由でインタプリタを複数個生成できるような設計にしたのですが、
Interpreter *create_interpreter();
というような関数を作ってレビューしたら、上司は「これはインタプリタの
ソースコードをジェネレートするのか」と言いまして、それは違うと
説明したのですがなかなかわかってもらえませんでした。
まあ、このときは私の説明の仕方も悪かったのかと思いますが。
私はこういう経験を何度もしていますので、「オブジェクト指向初心者に
分からないのは『インスタンス』である」と思っています。かなり自信を持って。
で、インスタンスとは何か、手続き指向プログラマが慣れ親しんだ
「モジュール」とは何が違うのか、と考えると、それは「インスタンスは
複数生成できる」ということでしょう。
「マルチプルインスタンス」が重要だと書いているのは、そういうことです。
>
> ん? 私は「Cプログラマには『メッセージ』なんか理解できない」と
> 言ってるわけではないですよ。
>
> 関数呼び出しとほぼ変わらないものを「メッセージ」などと呼ぶことが、
> 理解の妨げになっている、と言っているだけです。
そうですね、失礼しました。この部分までの認識は私も前橋さんも一緒なのではないか
と思います。（実は、もとの私の投稿の後半部分も同じこと言っているつもりなんですが。）
で、私としては、最初からメッセージで説明できる例を出して説明してしまえるん
だったら、そっちの方が理解が早いケースもあるんじゃないかと思っています。
MFCがあんまりいいお手本じゃないというのも、これに関係しています。というのも、
最初にMFCのGDI関係のオブジェクトを見たときの感想が、「WindowsAPIとどこが違うんだ？」
だったんですよ。「だったら、苦労してC++覚える必要ないじゃん」って。
私はどちらかと言うと、いままで知らなかった概念を最初に出してくれた方が新しい言語なり
開発環境に入りやすい方なんです。なんらかの驚きがないと、その先に進む気が失せるというか(^^;
> > > さっき、こんなの↓見つけました。
> > 分からない単語が沢山。(-0-;
> Javaのようなオブジェクト指向言語では、誰か一人「主役」を選ばなければならず、
> そこで不自然さが出てくることがあるわけです。
> [435]の引用にあるライトバルブとソケットのように。
私もわからない単語が多いと思ってました。
具体的には「LightBulb」objectと「socket」objectが何者なのかが。
最初、socketっていうから、networkで通信をするときの話だと思いこんでしまい
JavaでLightBulbってJavaで、どういうobjectなのか、
それらに対して、PutIn()がどういう操作を意味するのか
そもそも、通信用のsocket(object?)に「差し込む」ってどういう意味やネンって
感じで、全く意味が理解できませんでした。
...けど、これって、電球と受け口を使った例え話なんですよね?
気づかなかったなぁ。あほやん > 私 f^^;
# 私なら、socket.PutIn( LightBulb)かな。
> > たいてのオブジェクト指向言語では、誰か一人「主役」を選ばなければ
> > ならないので、そこで不自然さが出てくる場合もあるように思います。
>
> さっきも少し書きましたが、主役次第で呼び出し側の考え方がコロッと変わりますね。
> クラス設計者の意図を深く読み取らないとダメなのかな…なんていうのは大袈裟かな？
>
> > さっき、こんなの↓見つけました。
>
> 分からない単語が沢山。(-0-;
どうも舌足らずだったようで、自分で読み返しても[435]がどういう話の流れで
こういうことを書いているのかよくわからないので(^^; 補足します。
Javaのようなオブジェクト指向言語では、誰か一人「主役」を選ばなければならず、
そこで不自然さが出てくることがあるわけです。
[435]の引用にあるライトバルブとソケットのように。
だとすると、284さんが[428]で
>人間的には、DrawTextは”文字列描画”という
>目的がメインであり、DCは副次的に必要な要素に捉えるものではないかと思います。
と書かれたように、DrawTextという処理をメインに持ってくる方が自然なケースも
あるはずで、要は上記の部分に賛成したかったのでした。
せっかく開眼したところに水を差すようですみませんが。
私はマルチプルディスパッチについてはまさに付焼刃なんですが、
CLOSのようにマルチプルディスパッチが入ってくると、
「オブジェクトにメッセージを送って…」というメタファはどうなるんでしょうか。
> > 例が悪いのでそういう反論に対してうまく返事出来ないのですが、
> > DrawTextについてはDCを意識していても、GDIまでは意識しないのでは？
>
> それはそう思います。
> そして、意識しなくてよいのは、やっぱりGDIがひとつしかないからでは
> ないでしょうか。
うちゃさんのレスで開眼しました。(^-^;
> > 第１パラメータにDCを設定するようなAPI仕様にはなっていますが、フォントやカラー
> > と同じように、”デフォルトのDCを設定するAPI”というようなモノがもし存在する
> > のならば、DCを基点に考えることが出来なくなります。
> > （描画に関するハンドルをSelectObjectで設定しておけば、後の描画関連APIがそれを
> > 元に実行されるように）
>
> …という設計は、プログラムが大きくなると困るのでは。
> たとえばSelectDc()で「カレントのDC」が指定できるとして、
> プログラムのあちこちで勝手にカレントのDCを切り替えていると
> そのうちわけのわからないことになりそうです。
> まあ実際には「SelectDc()やった奴はちゃんと元に戻しとけ」という
> 規約で乗り切るのでしょうが、誰かがそれを破ると破綻してしまいます。
まあ、これは”たられば”の話ですので…。といってもSelectObjectは実在していて、
これについてはご指摘と同様の問題があるとは思います。
> オブジェクト指向において「誰が主役なのか」は、結構恣意的に決められている
> ように思いますね。うちゃさんのレスにあるように、
>
> > stringA.draw(dc,x,y);
>
> というクラス設計もありえます。
> たいてのオブジェクト指向言語では、誰か一人「主役」を選ばなければ
> ならないので、そこで不自然さが出てくる場合もあるように思います。
さっきも少し書きましたが、主役次第で呼び出し側の考え方がコロッと変わりますね。
クラス設計者の意図を深く読み取らないとダメなのかな…なんていうのは大袈裟かな？
> さっき、こんなの↓見つけました。
分からない単語が沢山。(-0-;
> 何に文字列を描画するのか？というのは重要かもですね〜。
> プリンタかもしれませんよ〜。
今までの経験では、画面・メモリ・プリンター位しか使ったことないですが、
複数のDCに対して同時に書き込む事は無かったので…。
あらかじめ描画先を指定している方がすっきりしそうな気がしていたのですよ。
（SelectDcみたいな）
> まぁ、逆に重要な無い、とも言えますけどね。オブジェクト指向
> だからこそ重要じゃなくなるわけでー。
クラス設計者次第でかなり左右されそうな気がしてきました…。
> 常に意識の外に置いておくわけにもいきません。
確かにそうです。
> XString stringA("ABCD");
> stringA.draw(dc,x,y);
>
> これだとオブジェクトは出力する文字列の数だけ存在しますよね。不思議に見える
> かもしれませんが、自分でオブジェクトを作る場合はこっちのパターンの方が
> よく使います。
この場合だと文字列の数だけ存在するというのに冗長性を感じますが、それはさて
おき、この場合のオブジェクトとメソッドの関係がよく分かります。
なるほどです。
メッセージを投げるという意味も分かるような気がしてきました。
> > 「オブジェクト指向の言語比較論」
> 早速読んでみますね(^^)
> > いいなぁ。そういう言語使える人はとか羨ましく思ってしまいます。
> 私もそろそろいい年なので頭が固くなりつつあり、一層そう思うのかも・・・
C言語で実装している例が、他の言語では数行で実現できているのを見るにつけ
いいなぁって指くわえちゃいます。
> そうそう。オブジェクト指向と言えばある意味、
> シェルから叩くコマンドもオブジェクトなんじゃないかと(^^;
> # というかプロセスかも？
うーん。ここで言ってるコマンドってどういうものを指してるんでしょうか?
私などはコマンドって言うとcp,mv,rm,grep,find,ps,less,sed,awk,...などが
思いついてしまうので「えっ、どこのどのへんが?」って思っちゃいましたが。
processを分離して、processに対して、特定のcommandを送る(kill,truss)とかは
ある意味、object(process)にmessege(command)を送っている感覚に近いですが
でも、継承もしない(できない)し、ちょっと違うような気もしますが?
> でも私は「ポインタ完全制覇」では、最初はやっぱりアドレスをprintf()の
> %pで表示させるところから説明を始めました。
確かに私もpointerって結局何?って思ってprintf("%p");しまくりました。
> 前にも書きましたが、
> 「人間誰でも低レベルの概念の方が理解が早い」と思っているからです。
結局、いきなり全く知らない概念を理解するなんて無理なわけで
今まで理解している概念に対して
a. 何が一番近いのか?
b. それと比べてどう違うのか?
c. それによって どんなmerit/demeritがあるのか?
d. それを実戦ではどの様に応用するか?
というstepを通じて新しい概念を理解・応用できるわけですから。
そういう意味では、続き(b,c)がないと理解が中途半端で終わっちゃうかも
しれません。
「ふーんメッセージを送るって言うのは関数呼び出しと同じなのか」と。
続き、期待してます。あまり負担にならない程度に。
> >>> 「あくまでmessageを送ることを実現するための「実装手段」として
> >>> たまたま関数呼び出しを使用しているということに過ぎず、
> >>> messageを送るという概念自体は、もっと抽象的なもの」
> ただ「メッセージ送信」が、関数呼び出しのより抽象的な概念に
> 位置するかというと、ちょっと違う気もします。
> 位置的には「斜め上」のような。少なくともJavaやC++においては。
確かに「ポインタ」と「アドレス」は「概念」と「実装」という意味で
直線上にありますが、「メッセージ」と「関数」は同じ直線上にはないですね。
> だとすると、核心に入るのはもうちょっと先のテキストですね。
> # この辺が随時追加のWebテキストの難しいところかも！？
というわけでさっさと先を書かなければいけないんですが…
ええと、すみません。(_o_) この週末に少しは…
> # 飲み会帰り〜♪前橋さんとバトルしたいという人発見:p
ええと、でしたらここに誘導していただければ (^^;
> XString stringA("ABCD");
> stringA.draw(dc,x,y);
>
> これだとオブジェクトは出力する文字列の数だけ存在しますよね。不思議に見える
> かもしれませんが、自分でオブジェクトを作る場合はこっちのパターンの方が
> よく使います。
>
> ＊ＭＦＣってお手本としてはいまいちなんじゃないかと思います。
とはいえJavaのjava.awt.GraphicsだってMFCライクな方のアプローチを
採用していますし、私もこっちのアプローチのほうが素直だと思います。
draw()メソッドをどこに置くべきか、という話は、私はあっちこっちに
書いてますが、とりあえずWebから参照できるのはoosquare-mlに投げた
これ↓ですね。
http://www.ogis-ri.co.jp/otc/otc2/oosquare-ml/Archive/200107.month/1884.html
> 例が悪いのでそういう反論に対してうまく返事出来ないのですが、
> DrawTextについてはDCを意識していても、GDIまでは意識しないのでは？
それはそう思います。
そして、意識しなくてよいのは、やっぱりGDIがひとつしかないからでは
ないでしょうか。
> 第１パラメータにDCを設定するようなAPI仕様にはなっていますが、フォントやカラー
> と同じように、”デフォルトのDCを設定するAPI”というようなモノがもし存在する
> のならば、DCを基点に考えることが出来なくなります。
> （描画に関するハンドルをSelectObjectで設定しておけば、後の描画関連APIがそれを
> 元に実行されるように）
…という設計は、プログラムが大きくなると困るのでは。
たとえばSelectDc()で「カレントのDC」が指定できるとして、
プログラムのあちこちで勝手にカレントのDCを切り替えていると
そのうちわけのわからないことになりそうです。
まあ実際には「SelectDc()やった奴はちゃんと元に戻しとけ」という
規約で乗り切るのでしょうが、誰かがそれを破ると破綻してしまいます。
> DrawTextでも、DCに対する文字列描画という機能のためにDCを基点にクラス構成
> するのがシンプルなのでしょうが、人間的には、DrawTextは”文字列描画”という
> 目的がメインであり、DCは副次的に必要な要素に捉えるものではないかと思います。
オブジェクト指向において「誰が主役なのか」は、結構恣意的に決められている
ように思いますね。うちゃさんのレスにあるように、
> stringA.draw(dc,x,y);
というクラス設計もありえます。
たいてのオブジェクト指向言語では、誰か一人「主役」を選ばなければ
ならないので、そこで不自然さが出てくる場合もあるように思います。
さっき、こんなの↓見つけました。
http://makotosatoh.jp/cgi-bin/wiliki.cgi?TinyCLOSTutorial&l=jp
| この区別は単に構文的なものだけではない。C++では、複数のオブジェクトを
| 巻き込むアクションは、パラメータの残りを伴って、それらのうちの1つに
| 属さなければならない。他の例としては、LightBulbとsocketという
| 2つのクラスがあるとして、ライトバルブをソケットに差し込む
| ポリフォルニズムを実現する関数を(他のものと一緒に) 書きたいと
| しよう。C++(やJava)では、プログラマはソケットを引数とする
| ライトバルブのメソッドを書くか、ライトバルブを引数とするソケットの
| メソッドを書くかを選択しなければならない。
あ、同時書き込みだ・・・(^^;
いつもお世話になってます。
> でも私は「ポインタ完全制覇」では、最初はやっぱりアドレスをprintf()の
> %pで表示させるところから説明を始めました。前にも書きましたが、
> 「人間誰でも低レベルの概念の方が理解が早い」と思っているからです。
確かに。
私もたまたまアセンブラやっててアドレスを弄っていたから
C言語をはじめてもポインタの理解が早かったわけですし・・・
だとすると、核心に入るのはもうちょっと先のテキストですね。
# この辺が随時追加のWebテキストの難しいところかも！？
> 私もそう思い↓の書き込みをしたのですが同意が得られなかったようです(^^;)
あ、ほんとだ・・・(^^;
やはりちゃんと読みきれていなかったのか・・・
同じこと繰り返してしまって、本多さん、皆さん失礼しました。(_o_)
> 「オブジェクト指向の言語比較論」
早速読んでみますね(^^)
> いいなぁ。そういう言語使える人はとか羨ましく思ってしまいます。
私もそろそろいい年なので頭が固くなりつつあり、一層そう思うのかも・・・
そうそう。オブジェクト指向と言えばある意味、
シェルから叩くコマンドもオブジェクトなんじゃないかと(^^;
# というかプロセスかも？
そう考えると、プログラムのオブジェクトにも
仕事渡されるまで（コマンド叩かれるまで）動かない「受動的なオブジェクト」と
デーモンのようにいつも求人情報を閲覧しているような「能動的なオブジェクト｣
なんて考え方ができそうですね。（「能動・受動」は便宜上でっち上げました。）
# Windowsのメッセージループとコールバック関数の関係とか。
# あ。スレッドもそうか・・・
ということになると、あるオブジェクトに対して明示的にメッセージを返さなくても、
「あるオブジェクトが監視しているオブジェクト達の動き」もメッセージになってしまって、
「メッセージ＝関数呼び出し」という枠では収まらないかもしれないです(^^;
というのが今日思ったことです。
# 整理できてないので言っていること変かも(^^;;;;;;;;
> 論争を流し読みしていて思ったのですが、
> 「メッセージ＝関数呼び出しとするのは、
> ポインタ＝アドレスと決め付けて説明してるくらい乱暴な説明なのかも！？」
> というような考えが頭をよぎりました。
いや、わかります (^^;
でも私は「ポインタ完全制覇」では、最初はやっぱりアドレスをprintf()の
%pで表示させるところから説明を始めました。前にも書きましたが、
「人間誰でも低レベルの概念の方が理解が早い」と思っているからです。
本多さん:
>>> 以前、(ぱ)さんが「よた話」の「ポインタ」の中で
>>> 「あくまでポインタを実現するための「実装手段」として
>>> たまたまアドレスを使用しているということに過ぎず、
>>> ポインタという概念自体は、もっと抽象的なものである筈です」
>>> と、おっしゃっているのと同じようにmessageを送るというのは
>>> 「あくまでmessageを送ることを実現するための「実装手段」として
>>> たまたま関数呼び出しを使用しているということに過ぎず、
>>> messageを送るという概念自体は、もっと抽象的なもの」
>>> じゃないでしょうか?
ただ「メッセージ送信」が、関数呼び出しのより抽象的な概念に
位置するかというと、ちょっと違う気もします。位置的には「斜め上」のような。
少なくともJavaやC++においては。
今週は仕事と飲み会(^^; に追われておりまして、返事が遅くなりまして
すみません。
> CとWindowsAPIを使ってきた人が混乱するのは、メッセージメタファ
> そのものが原因ではないのではないかと思います。
> 「オブジェクト間でメッセージ通信をしながら協調動作する」という
> モデル自体はCからWindowsAPIを使う場合でも提示されているので、
> 意識しているかどうかはわかりませんが受け入れているんですよ。
> （受け入れていないとコード書けません。）
ん? 私は「Cプログラマには『メッセージ』なんか理解できない」と
言ってるわけではないですよ。
関数呼び出しとほぼ変わらないものを「メッセージ」などと呼ぶことが、
理解の妨げになっている、と言っているだけです。
> 第１パラメータにDCを設定するようなAPI仕様にはなっていますが、フォントやカラー
> と同じように、”デフォルトのDCを設定するAPI”というようなモノがもし存在する
> のならば、DCを基点に考えることが出来なくなります。
> （描画に関するハンドルをSelectObjectで設定しておけば、後の描画関連APIがそれを
> 元に実行されるように）
>
確かに、文脈によってはDCはそれほど強く意識する必要のないオブジェクトかもしれません。
とはいえ、ダブルバッファ化する場合のようにメモリ上にもう一つ作ったりもしますから、
常に意識の外に置いておくわけにもいきません。
> DrawTextでも、DCに対する文字列描画という機能のためにDCを基点にクラス構成
> するのがシンプルなのでしょうが、人間的には、DrawTextは”文字列描画”という
> 目的がメインであり、DCは副次的に必要な要素に捉えるものではないかと思います。
ここで、ちょっとＭＦＣから離れてみましょう。何をオブジェクトとしてとらえるか。
DCではなくて、文字列の方をオブジェクトにして、文字列オブジェクトにdrawメソッド
をつけるという手があります。コードにするとこんな感じですかね。
XString stringA("ABCD");
stringA.draw(dc,x,y);
これだとオブジェクトは出力する文字列の数だけ存在しますよね。不思議に見える
かもしれませんが、自分でオブジェクトを作る場合はこっちのパターンの方が
よく使います。
＊ＭＦＣってお手本としてはいまいちなんじゃないかと思います。
> DrawTextでも、DCに対する文字列描画という機能のためにDCを基点にクラス構成
> するのがシンプルなのでしょうが、人間的には、DrawTextは”文字列描画”という
> 目的がメインであり、DCは副次的に必要な要素に捉えるものではないかと思います。
何に文字列を描画するのか？というのは重要かもですね〜。
プリンタかもしれませんよ〜。
まぁ、逆に重要な無い、とも言えますけどね。オブジェクト指向
だからこそ重要じゃなくなるわけでー。
# 飲み会帰り〜♪前橋さんとバトルしたいという人発見:p
> > ジュース自販機.お金投入()
> > ジュース自販機.ボタン押下()
> > ジュース自販機.商品取出し()
> > タバコ自販機.お金投入()
> > タバコ自販機.ボタン押下()
> > タバコ自販機.商品取出し()
>
> うーん、このたとえだと、「ジュース自販機」と「タバコ自販機」が、
> インスタンスが異なるだけなのか、それともクラスも異なるのかが
> 不明確だと思います。もし、これが別クラスで、これらが「自販機」の
> サブクラスだとすると、ポリモルフィズムが絡んできそうです。
あまり深く考えていませんでしたが、同クラスもしくは似たようなクラスという
認識です。
書きたかったのは”所在”よりも”目的”を意識している事が多いです。という
ことですね。（お金投入()〜商品取出し()）
> > カーネル（だっけ？）.FileCopy()
> > GDI.DrawText()
> > というのも、実際には所在なんて気にしないでFileCopyやDrawTextを使いますし。
>
> FileCopy()の場合、「カーネル」の所在を気にしなくてよいのは、
> 「カーネル」が「ひとつしかない」からですよね。
> DrawTextの場合、DCの所在がわからないと使えません。
> DCはひとつではないからです。
例が悪いのでそういう反論に対してうまく返事出来ないのですが、DrawTextについて
はDCを意識していても、GDIまでは意識しないのでは？
Winの３大モジュール(?)である、KARNEL・USER・GDIという諸元なんて意識しないのでは？
という事です。
DrawTextでも、DCに対する文字列描画という機能のためにDCを基点にクラス構成
するのがシンプルなのでしょうが、人間的には、DrawTextは”文字列描画”という
目的がメインであり、DCは副次的に必要な要素に捉えるものではないかと思います。
例えば、DrawTextで使用されるフォントやカラーはあらかじめ設定されている情報を
元に使用されます。
第１パラメータにDCを設定するようなAPI仕様にはなっていますが、フォントやカラー
と同じように、”デフォルトのDCを設定するAPI”というようなモノがもし存在する
のならば、DCを基点に考えることが出来なくなります。
（描画に関するハンドルをSelectObjectで設定しておけば、後の描画関連APIがそれを
元に実行されるように）
もちろん、現実的にはDCを基点にしていること（特にMFC）を否定する訳ではありませんが。
> 論争を流し読みしていて思ったのですが、
> 「メッセージ＝関数呼び出しとするのは、
> ポインタ＝アドレスと決め付けて説明してるくらい乱暴な説明なのかも！？」
> というような考えが頭をよぎりました。
私もそう思い↓の書き込みをしたのですが同意が得られなかったようです(^^;)
>> 以前、(ぱ)さんが「よた話」の「ポインタ」の中で
>> 「あくまでポインタを実現するための「実装手段」として
>> たまたまアドレスを使用しているということに過ぎず、
>> ポインタという概念自体は、もっと抽象的なものである筈です」
>> と、おっしゃっているのと同じようにmessageを送るというのは
>> 「あくまでmessageを送ることを実現するための「実装手段」として
>> たまたま関数呼び出しを使用しているということに過ぎず、
>> messageを送るという概念自体は、もっと抽象的なもの」
>> じゃないでしょうか?
もっとも関数は「実装手段」というのはちょっと御幣がありそうです。
> そうなるともうちょっと噛み砕いた説明が必要になるのかも、と思いました。
> # 「メッセージと関数呼び出し完全制覇」が必要！？・・・欲しいかも（ぉ
若干、趣旨は異なりますが以前、
こちらにも書き込みをされていらっしゃったmkinoさんの作った
「オブジェクト指向の言語比較論
(http://homepage.mac.com/mkino2/oop/index.html)」
というpageは、各言語の実装比較として 整理されていて
基本がわかっている人には興味深い&面白いと思います。
C言語も含まれてて、根性モノだなぁとか思っちゃうのですが。
こうやって比較すると高級なprogramを作るなら
高級言語ってよさそうだなぁとか感じます。
いいなぁ。そういう言語使える人はとか羨ましく思ってしまいます。
> 部下とか子分ってイメージ(^^)
私もそんなイメージですね。
「じゃぁ、これでやっておいて」というか。
# ただ、中身を知っている場合は
# 「こうすればこうなる」的に記述してしまいますけど（私だけ？）
論争を流し読みしていて思ったのですが、
「メッセージ＝関数呼び出しとするのは、
ポインタ＝アドレスと決め付けて説明してるくらい乱暴な説明なのかも！？」
というような考えが頭をよぎりました。
そうなるともうちょっと噛み砕いた説明が必要になるのかも、と思いました。
# 「メッセージと関数呼び出し完全制覇」が必要！？・・・欲しいかも（ぉ
横槍しつつ、コメント多々な乱文で失礼します。
# 半・デスマーチPJにいるので、じっくり読めてません。すいません。(_o_)
> > 関数に「○○してください。」とお願いする、という感覚は、
> > Cプログラマであっても持っているはずです。
> > printf("hello, world.\n"); は、printfという関数に、
> > 「"hello, world.(改行)"と表示してね」とお願いしているのです。
> 私や私のまわりの人々はもってないですね。
だとするなら、関数の呼び出しが何かの処理の依頼という感覚じゃないとしたら
どういう感覚なのでしょう?
他人の作った関数を呼びだすとき、
何かの処理を依頼する感覚じゃないんですか?
printf()だと、「お願い」じゃなくて「命令」という感覚はありますが。
部下とか子分ってイメージ(^^)
>
> ですから、WindowsのCレベルのAPIでは、DCがDrawTextの第1引数になっていますし、
> MFCではDrawTextはDCのメソッドです。「疑りぶかい〜」では
> | オブジェクト指向言語では、「どのオブジェクトを操作するか」を、
> | 第1引数で指定するのではなく、関数の左側に書く。
> と書いていますが、これはそういう意味で書きました。
>
> だからといって、これを
>
> > この形を”メッセージ”だよ。”関数呼出しとは違うよ”と言われたら、混乱します。
>
> 「”メッセージ”だよ。”関数呼出しとは違うよ”」と言われたら
> そりゃ混乱しますよねえ。
CとWindowsAPIを使ってきた人が混乱するのは、メッセージメタファそのものが原因では
ないのではないかと思います。
「オブジェクト間でメッセージ通信をしながら協調動作する」というモデル自体はCから
WindowsAPIを使う場合でも提示されているので、意識しているかどうかはわかりませんが
受け入れているんですよ。（受け入れていないとコード書けません。）
ところが、VC++とMFCでは、せっかく提示されているこのモデルを言語仕様のなかに
うまく取りこめていません。WindowsAPIで言うWindowオブジェクトに対するメッセージ
送信のイメージがあるところに、C++のメソッド呼び出しを見れば関数呼び出しにしか
見えないのも当然でしょう。
> ジュース自販機.お金投入()
> ジュース自販機.ボタン押下()
> ジュース自販機.商品取出し()
> タバコ自販機.お金投入()
> タバコ自販機.ボタン押下()
> タバコ自販機.商品取出し()
うーん、このたとえだと、「ジュース自販機」と「タバコ自販機」が、
インスタンスが異なるだけなのか、それともクラスも異なるのかが
不明確だと思います。もし、これが別クラスで、これらが「自販機」の
サブクラスだとすると、ポリモルフィズムが絡んできそうです。
> カーネル（だっけ？）.FileCopy()
> GDI.DrawText()
> というのも、実際には所在なんて気にしないでFileCopyやDrawTextを使いますし。
FileCopy()の場合、「カーネル」の所在を気にしなくてよいのは、
「カーネル」が「ひとつしかない」からですよね。
DrawTextの場合、DCの所在がわからないと使えません。
DCはひとつではないからです。
ですから、WindowsのCレベルのAPIでは、DCがDrawTextの第1引数になっていますし、
MFCではDrawTextはDCのメソッドです。「疑りぶかい〜」では
| オブジェクト指向言語では、「どのオブジェクトを操作するか」を、
| 第1引数で指定するのではなく、関数の左側に書く。
と書いていますが、これはそういう意味で書きました。
だからといって、これを
> この形を”メッセージ”だよ。”関数呼出しとは違うよ”と言われたら、混乱します。
「”メッセージ”だよ。”関数呼出しとは違うよ”」と言われたら
そりゃ混乱しますよねえ。
> えーと、いま委譲という言葉は
私は単純に「あるオブジェクトから他のオブジェクトに処理を丸投げすること」
という程度の意味で書いていますが…
> 「オブジェクトの再利用における継承と委譲」の委譲として
> 扱われているのでしょうか？
オブジェクトの再利用の手法として、継承を使う方法と委譲を使う方法が
ありますが、その場合の「委譲」も
「あるオブジェクトから他のオブジェクトに処理を丸投げすること」
に変わりはないのでは?
> > つまり、カプセル化は、別にオブジェクト指向に固有の概念ではありません。
>
> そのとおりですが、「カプセル化」というコンセプトを
> 用語として定義していることが重要です。
> それまでには、あなたのいうようなことを端的に
> あらわす言葉はなかったはずです。
「モジュール」でいいんでは?
Modula2なんかは言語の名前にまで「モジュール」が顔を出していますし。
実は「モジュール」というのはかなり定義が曖昧な言葉で、
その辺のことは「C言語ヨタ話 モジュールと命名とヘッダファイルと」に
書いたのですが、
http://member.nifty.ne.jp/maebashi/programmer/c_yota/module.html
サブルーチンであろうと.cファイルだろうと、実装を隠蔽できる塊であることに
変わりはないわけですし。