K.Maebashi's BBS

>>そして、それらの側面が無いと、いわゆる「手続き型」と、何も変わりが無いのでは、と思います。つまり、データと手続きをセットにするということ自体は、「手続き型」言語でも容易に可能なわけですから。 > >「手続き型言語」と「手続き型プログラミング」、 >「オブジェクト指向言語」と「オブジェクト指向プログラミング」は分けて考えるべきだと思います。 もちろん、それはそうだと思います。 なので、 >>「手続き型」言語でも容易に可能 と、「容易に」と書いた訳です。 逆に言えば、動的結合や多態は、いわゆる「手続き型」言語では、容易には実装できない、と言いたかったのでした。 極論するならば、全ての言語も対等で、どの言語でも、他の言語で実装可能な機能は、どんな内容でも実装可能なはずです。 でも、それが容易であるか容易でないかの違いは、かなり大きいと思います。

＃追記 >>という側面が無いと、動的結合や多態は、説明できないのではないのかぁ、と思いました。 > >個人的な考えとしては、動的結合も多態性も、責務の分離をはっきりさせるための手段でしかないと思います。 つまり、動的結合や多態性がない「オブジェクト指向」があってもいいのではないか、ということです。

>という側面が無いと、動的結合や多態は、説明できないのではないのかぁ、と思いました。 個人的な考えとしては、動的結合も多態性も、責務の分離をはっきりさせるための手段でしかないと思います。 以前は何でもかんでもバグを減らすための手段と捉えて失敗しましたが、「責務の分離」を目的に置いてみることにしました。 >そして、それらの側面が無いと、いわゆる「手続き型」と、何も変わりが無いのでは、と思います。つまり、データと手続きをセットにするということ自体は、「手続き型」言語でも容易に可能なわけですから。 「手続き型言語」と「手続き型プログラミング」、 「オブジェクト指向言語」と「オブジェクト指向プログラミング」は分けて考えるべきだと思います。 Java 使ってもオブジェクト指向っぽくないプログラムは作れるし、C 言語でもオブジェクト指向プログラミングはできます。 あと、C に端を発する C++ とか Java とかの言語は、「手続き型オブジェクト指向言語」だと思います。 「手続き型言語」の対義語は「関数型言語」らしいので。

# すみません、また発散させてしまいます。。 >「自分にできることを自分自身が知っている」のがＯＯだと思っていますが、違うのでしょうか？ そっかー。 ・ （データや手続きの）所属がはっきりしている というのは、オブジェクト指向の根幹な気がしてきました。目から鱗です。 でも、それからさらに少し考えてみたんですが、 ・ オブジェクトは複数生成できる。 ・ 生成されたオブジェクトは、ユニークである という側面が無いと、動的結合や多態は、説明できないのではないのかぁ、と思いました。 そして、それらの側面が無いと、いわゆる「手続き型」と、何も変わりが無いのでは、と思います。つまり、データと手続きをセットにするということ自体は、「手続き型」言語でも容易に可能なわけですから。

オブジェクト指向では「責務の分離」が大切。 平たく言えば、オブジェクトを使う上で、知っていなければならないこと、知らなくてもいいこと、知っていてはならないことがきちんと分かれていること。 > 「自分にできることを自分自身が知っている」のがＯＯ 自分自身は「何ができるか」と「どうやるか」を知っているけれど、他人には前者だけ教えておけばいい。 うーん…これを一言で言ったものが「抽象化」ということなんだろうか。 オブジェクト指向のキモは「抽象データ型」？ 「型」という概念がない言語もあるだろうから、「抽象データ」かな。 してみるに、カプセル化も継承も多態性も実装隠蔽もメッセージパッシングも、すべてはこれをサポートするためのものでしかないことがわかる。 マルチプルインスタンスは…申し訳ないが、抽象データとはちょっと関係なさそう？ うん、何だか、散々語り尽くされたところに落ち着いてしまった感がある。 現時点でのマイ定義： 「オブジェクト指向とは、データの抽象化によってバグを減らすための技術である」。 私の失敗は、いろんなものを同一視しすぎたこと。 例えば ・類似のコードをサブルーチンに分けるのは、コード修正の際に書き換える箇所を少なくすることによってバグを減らす技術。 ・データの抽象化は、オブジェクトを「使う側」のコードを再利用することによって、修正の必要性を軽減する技術。 ・ほら、この２つは結局同じ（コードを書き換える量を減らすのを目的とした）ことだ。 ここまで一般化してしまったから、わけがわからなくなってしまった。 サブルーチンの切り出しは、責務の分離とまったく関係が無い。だからこれを同一視してはいけなかった。 ＃我ながら、実に「何を今更」だな。 ＃ツッコミお待ちしています。

>発散していてどこにつけていいかわからないので新規投稿。 ここにまとめレス。 > たとえば、以下のページでは、 > http://www.shiro.dreamhost.com/scheme/trans/reesoo-j.html > オブジェクト指向言語の要件を箇条書きにしたうえで、 極論、この一覧の要件をひとつでも満たせば、あるいは、ここに無いけれど何か妥当っぽい特徴を持っていれば、そして、その言語がオブジェクト指向であると主張すれば、それはオブジェクト指向になってしまうのかもしれない。 この一覧には > 全てはオブジェクトなり - 全ての値はオブジェクト。Smalltalkでは真だが、 Javaでは (int等のため) 真ではない。 とある。「オブジェクト」の定義にもブレがあるだろうが、これに従って解釈すると、 > int i; > int j; > これでマルチプルインスタンス、ってのはヒネクレ過ぎ？ これを Java のコードとして見るならば、i や j はインスタンスではあるがオブジェクトではないのだろう（i や j をオブジェクトと呼ぶときの「オブジェクト」と、「オブジェクト指向」の定義を語るときの「オブジェクト」は意味が違うのは明らかだしね）。 > カプセル化のない(今はあるんでしたっけ?)のPythonとか、 > メソッドとオブジェクトを実行時にくっつけるPerlとか、 > メソッドとオブジェクトが直接関連していないCLOSとか… うーん…それらの言語については、というか、C++ / C# / Java あたりの C ファミリーしか私は知らないんですが。 ただ、前に述べたとおり、Win32 API のメッセージアーキテクチャはオブジェクト指向なので、「メソッドとデータの結合」は必須要件ではないんだろう。 > Simulaは、むしろC++に近い言語だという認識です。 コードを見た感じ、そうみたいですね。 どうも私は（偏見というか思いっきり間違いなのですが）Simula と Smalltalk を同一視してしまう。 Smalltalk はオブジェクト指向云々以前に関数型言語なので、C++ や Java とは同列で比較しにくいものがあるけれど。 > 全メンバが static なクラスってのを使います。 > 拡張性０ですがこれも立派なクラスだと思っております。 > 「自分にできることを自分自身が知っている」のがＯＯ 確かに。 でも、（static メンバでもいいから）何らかのデータを持っていないと、それはクラスだけどオブジェクト指向とは言い難いような気がします。 「自分」ってのは「データ」のことだと思うから。

発散していてどこにつけていいかわからないので新規投稿。 マルチプルインスタンスでないオブジェクト指向というか C++ ソースを結構書いている 身としては、マルチプルインスタンスが必須といわれてしまうとちょと悲しいかも。 組み込み系の仕事をしていると「＊＊＊が１つ、△△△が１つ」なんてのはよくあるのです。 顧客要望的にも、コスト的にも、２つになることは決してありえない、って状況。 そーいう場合に＊＊＊の制御を行うクラスとして class ***_t { static int Flags; static void CheckABC(); public: static bool IsXYZ(); }; のように、全メンバが static なクラスってのを使います。 拡張性０ですがこれも立派なクラスだと思っております。 「自分にできることを自分自身が知っている」のがＯＯだと思っていますが、違うのでしょうか？ たまたまその結果として複数インスタンスの利用が簡単になっているのだと考えますが。

「インスタンス」という意味であれば構造体であれ クラスであれmallocしたメモリであれインスタンス には違いないわけです。 マルチプルインスタンス＝オブジェクト指向と言い 切ってしまうと、それはちと問題かなと思います。 まあ実際言葉の定義（オブジェクト指向とは何ぞや） なんかはどうでもよくて、作りやすくてバグが減る のなら何でもいいと個人的には考えています。 そういう「なんでもいいじゃん」的な考え方でいく と、C++の汚い文法よりはJavaなんかのほうが洗練 されていて好みですね。Javaの仕様でネイティブ バイナリを吐くコンパイラがほしいです。 あったらすごい売れそう。

>（あっちから覗かれてないことを祈りつつビクビク書きこむけれど） >Simula っぽくないとオブジェクト指向とは認められない、とか言わないよね… 詳しいわけではないですが、Simulaは、むしろC++に近い言語だという認識です。 http://www.cee.hw.ac.uk/~rjp/bookhtml/chap09.html Example 9.4のあたりを見ると、メソッドは「procedure」として宣言されてますし。

ええと、chatモード? >ところで、C で > >int i; > >と書いたとき、これは（int クラスではないけれど）int 型のインスタンスと >呼べはしまいか。 >int 型のオブジェクトと呼んでも、間違いとは言えまい。 ていうかK&Rでは、これのことをオブジェクトと呼んでますね。 >オブジェクト指向っていうと「データと関数をくっつけたものがオブジェクトです」と >いう説明がなされることが多いが、いわゆるカプセル化というのは必須要件では >ないのだろうか。 カプセル化のない(今はあるんでしたっけ?)のPythonとか、 メソッドとオブジェクトを実行時にくっつけるPerlとか、 メソッドとオブジェクトが直接関連していないCLOSとか…

>| つまり、「オブジェクト指向」というのはちゃんと定義された概念ではない。 ふむ、結局そんなもんなんですか。 >でも、最低限、オブジェクト指向の必要条件(十分条件でないことは承知の上で)を >言うのであれば、「マルチプルインスタンス」は結構外せない線と言えると思います。 >インスタンスとはすなわちオブジェクトであり、オブジェクトがなければ、 >さすがにオブジェクト指向とは呼べないでしょうから。 ところで、C で int i; と書いたとき、これは（int クラスではないけれど）int 型のインスタンスと呼べはしまいか。 int 型のオブジェクトと呼んでも、間違いとは言えまい。 んで int j; これでマルチプルインスタンス、ってのはヒネクレ過ぎ？ オブジェクト指向っていうと「データと関数をくっつけたものがオブジェクトです」という説明がなされることが多いが、いわゆるカプセル化というのは必須要件ではないのだろうか。

>で、私の考えるオブジェクト指向とは、 > >「クラス（部品）を作り、組み合わせてアプリケーションを作る」 これだけだと、「ライブラリ」あるいは「モジュール」と、「クラス」との 区別が曖昧になってしまうのではないでしょうか。 Nさんが、 http://kmaebashi.com/programmer/object/othello.html こちらのページにある、static指定でカプセル化を図ったC版board.cを オブジェクト指向とみなすのであれば別ですが、 静的にひとつしかないboard.cモジュールは非OOで、 create_board()関数により複数のBoardを作ることができる版はOO的である、 ということに同意されるのであれば、マルチプルインスタンスが(すくなくとも クラスベースのOOにとって)必要条件であるということにも同意されるはずだと 思うのですが。 というわけで、 >なので「マルチプルインスタンス＝オブジェクト指向」 >という説にはあえて反対しておきたいと思います。 >そんな大げさなもんではないと私は考えています。 こちらもよくわかりません。しかも、上記のご意見は、その前段に >関数ポインタ（複数）とそれを操作するデータ（構造体） >をパッケージングすることで実現するというのは、 >C++への移行期であった当時は「なるほど」と思った >ものです。 とあります。私の認識では、これは立派なマルチプルインスタンスです。 http://kmaebashi.com/programmer/object/intro.html ここで、C++ FAQから引用し、 | もしCでマルチプルインスタンスが必要なら、プログラマは構造体を使いますが、 | こっちはカプセル化をサポートしません。 と書いているように。

管理人である私のいないところで会話が進んでいくのが、この手の掲示板の あるべき姿だと思ってます。皆様書き込みありがとうございます。 >じゃあ「オブジェクト指向」という言葉の定義は何かというと、詰まってしまって… 用語定義に拘泥するのはあまり意味があるとは思えないんですが、 無意味なことにこだわるのも人間だってことで。 たとえば、以下のページでは、 http://www.shiro.dreamhost.com/scheme/trans/reesoo-j.html オブジェクト指向言語の要件を箇条書きにしたうえで、 | つまり、「オブジェクト指向」というのはちゃんと定義された概念ではない。 | ある人々 (AbelsonとSussman?) はLispはオブジェクト指向だと言うが、それは | {3,4,5,7} に基づく (但し、全ての型はプログラマの頭の中に存在するとする)。 | Javaは {1,2,3,7,8,9} があるからオブジェクト指向だ。 Eは {1,2,3,4,5,7,9} と | 6のほとんどをもつから、もっとオブジェクト指向だと言えるかもしれない。 (中略) | オブジェクト指向というものが動く標的であるため、オブジェクト指向の熱心な | 支持者はこのメニューのうちの適当なサブセットを気まぐれに選んで、 | それを以って他の言語はオブジェクト指向ではないと説得しようとする。 と述べています。実際、その通りだと私も思います。 でも、最低限、オブジェクト指向の必要条件(十分条件でないことは承知の上で)を 言うのであれば、「マルチプルインスタンス」は結構外せない線と言えると思います。 インスタンスとはすなわちオブジェクトであり、オブジェクトがなければ、 さすがにオブジェクト指向とは呼べないでしょうから。 ただ、マルチプルインスタンスという定義自体、クラスベースのOOに特化してないか、 と言われるとそれはそうかもしれず。プロトタイプベースの場合、(ある特定の クラスの)インスタンスが複数生成される、というわけではないですから。 # プロトタイプベースの言語でも、結局クラスっぽいものを作ることが # 多いとは思いますけどね。

>ただ、これは個人的な感性の問題かもしれませんが、僕個人は、抽象化によって得られるメリットは、 > >「バグが減るから嬉しい」 > >よりも、 > >「表現力が高まるから嬉しい」 > >って側面の方が強いように思えます。 > ># 個人の主観の問題に還元しちゃうのは、ちょっとおもしろくないですけど。。 まだ個々人の主観を越える同意が得られる段階ではないんでしょうか？ 決して新しいものではないと思うんですけどね。 >>くだんの再入門にかぎらず、世の多くの「オブジェクト指向入門」が入門の先に見据えているものは、 >>実は、オブジェクト指向なんかじゃなく（実際、ほとんどその説明のために行を割いておらず） >>オブジェクトのメリットを論じたり、オブジェクトを使った効率的なプログラミングをするためのもの >>に過ぎないんじゃないかなぁ…という問題も、もちろんあります。 > >えーっ。 >それじゃ駄目なの？？？ > >って思ってしまいました。 「オブジェクトを使って効率的にプログラミングすること」って「オブジェクト指向」じゃないのかな？ それとも、あくまで「オブジェクト指向とは何か？」っていう説明をせよということなのかしら。 ＃私は知りたいけれど、入門者には必要か？　と思う （あっちから覗かれてないことを祈りつつビクビク書きこむけれど）Simula っぽくないとオブジェクト指向とは認められない、とか言わないよね…

>という話になると、結局、「バグが減るから嬉しい」に帰結するんじゃないでしょうか。 それもありだと思います。 ただ、これは個人的な感性の問題かもしれませんが、僕個人は、抽象化によって得られるメリットは、 「バグが減るから嬉しい」 よりも、 「表現力が高まるから嬉しい」 って側面の方が強いように思えます。 # 個人の主観の問題に還元しちゃうのは、ちょっとおもしろくないですけど。。 >余談になりますが、このサイトの「オブジェクト指向再入門」に言及されているページを見つけました。 >http://sumim.no-ip.com:8080/wiki/755 ↑このリンク先から引用 >くだんの再入門にかぎらず、世の多くの「オブジェクト指向入門」が入門の先に見据えているものは、 >実は、オブジェクト指向なんかじゃなく（実際、ほとんどその説明のために行を割いておらず） >オブジェクトのメリットを論じたり、オブジェクトを使った効率的なプログラミングをするためのもの >に過ぎないんじゃないかなぁ…という問題も、もちろんあります。 えーっ。 それじゃ駄目なの？？？ って思ってしまいました。

突っ込まれると思うので一応言い訳しておくと、 Cでも擬似マルチプルインスタンス的な作り方は 可能です。 とある人の書いたソースでは、typedefした構造体 に関数ポインタを持たせ、同じ機能で複数の状態 を持った「オブジェクト（インスタンス）もどき」 を使って機能を実現していました（某パズルですが）。 関数ポインタ（複数）とそれを操作するデータ（構造体） をパッケージングすることで実現するというのは、 C++への移行期であった当時は「なるほど」と思った ものです。 なので「マルチプルインスタンス＝オブジェクト指向」 という説にはあえて反対しておきたいと思います。 そんな大げさなもんではないと私は考えています。 強いて言うなら「設計概念の１つです」とでも言えば 十分じゃないでしょうか。

はじめまして。面白く読ませていただきました。 思うに、Cなどでは構造化設計に始まり、原始的な オブジェクト指向的設計まである程度踏み込んで いたのではないかと思います。この点は同じ論を 唱えていらっしゃると思います。 ただ、手続き型言語では「オブジェクト指向設計」 とは「呼んでいなかった」だけではないかな、と 個人的には思っています。 Cで言うと、 ・データを持つオブジェクトが操作方法を知っている 　＞より緻密なソースファイル分割 　＞関数名のルール付け 　＞データ操作関数のファイル内限定 ・インターフェースの限定による（使用者から見た）隠蔽 　＞static関数、ファイル内static変数（privateメンバに相当） ・ポリモーフィズム、継承、同じ動作は同じ名前に 　＞これはクラス型言語にしかできない機能ですね これらを、言語仕様面からより便利に使えるように したのがC++なりJavaなりであって、オブジェクト指向 のような概念的なことは（意識するしないをおいて） 近代の開発では行っていたと思います。 で、私の考えるオブジェクト指向とは、 「クラス（部品）を作り、組み合わせてアプリケーションを作る」 ことであると考えています。七面倒くさい用語はそれを 表現するための方便に過ぎないと。 このような（オブジェクト指向的）作り方をすると、手続き 型言語で感じていた以上に、ライブラリ的立場の部品と本来 のアプリケーション的立場の部品をいやでも意識させられる ことになります。 従来であれば、「じゃあこの機能とこの機能は整理して別に ライブラリ化しよう」ということになるのでしょう。それは クラス型言語でも可能だと思いますが、クラス型言語なら、 ライブラリ化という結構エネルギーを使う作業をしなくても クラス単位で再利用という手軽な使い方ができるのは１つの メリットかと思います。 長くなりましたのでこのへんで。

だんだんこちらのサイトのコンテンツの内容と関係なくなってきましたので、タイトル変えました。 >横槍、失礼します。 横槍大歓迎です。 >でも、オブジェクト指向って、再利用だけが利点でしょうか？ >オブジェクト指向に限らず、「抽象化すること」によって得られる利点を、適当につらつらと考えてみましたが、 > >・ 設計の向上（データ構造、モジュール間の関連等） >・ 可読性の向上 >・ 保守性の向上 >・ 意思疎通の向上 > >等々、ちょっと考えただけでも色々出てきそうです。 うん、なるほど。 確かに抽象化と再利用を直結させるのは短絡的ですね。 が、もう一歩突っ込んで、 ・何のために設計をはっきりさせるん？ ・可読性や保守性が向上するとどんなメリットがあるん？ ・意思疎通が円滑になるとどのように嬉しいん？ という話になると、結局、「バグが減るから嬉しい」に帰結するんじゃないでしょうか。 ＃とか言ってるとそのうち「より儲かるから嬉しい」に帰結しそうで、身も蓋もなくなってくるんですが。 はじまりは 「わけわからんたとえ話よりも、『オブジェクト指向を使うと何が嬉しいのか』に重きを置いて説明すべきではないか」 にあります。 C 言語の知識がある前提でオブジェクト指向を教えるとすると、何が嬉しいのかと言えばやっぱり「バグが減る・バグが出にくくなるから嬉しい」んだと思います。 ＃設計がきれいになることによってもたらされるメリットではなく、きれいになること自体が純粋に嬉しい、というのも共感できるところではあるのですが。 もうこうなると、オブジェクト指向のどこがいいのか、バグさえ減るならオブジェクト指向じゃなくたっていいじゃないか、ということになってしまうので、私の意見はやっぱりどこか間違えてるっぽいんですが。 括りすぎ、一般化し過ぎたんでしょうか。 そもそも「オブジェクト指向」という言葉の定義からして統一されたものがない…とも聞きますが。 余談になりますが、このサイトの「オブジェクト指向再入門」に言及されているページを見つけました。 http://sumim.no-ip.com:8080/wiki/755

横槍、失礼します。 >>>バグを減らすにはどうすればいいかというと、極力コードを書き起こす量、 >>>き換える量を減らすことです。 >>>継承や多態性は抽象化のための手段であり、抽象化は再利用のための手段であり、 >>>利用はコードを書く量を減らすための手段であると思います。 (中略) >「オブジェクト指向はバグを減らすための技術である」は真であると思いますが、「バグを減らすための技術はオブジェクト指向である」これは偽です。 (中略) >カプセル化も継承も多態性も「ソースコードを量を減らし、バグを減らすための手段である」と括ってしまうと、「バグを減らすための技術はオブジェクト指向である」が真になってしまうので。 確かに、 1) バグを減らすには、コード量を減らすことである 2) オブジェクト指向による抽象化は、再利用のための手段である 3) 再利用によってコード量が減る 4) コード量が減れば、バグが減る 5) オブジェクト指向は、バグを減らすための技法である という論理の筋は、理解できます。 でも、オブジェクト指向って、再利用だけが利点でしょうか？ オブジェクト指向に限らず、「抽象化すること」によって得られる利点を、適当につらつらと考えてみましたが、 ・ 設計の向上（データ構造、モジュール間の関連等） ・ 可読性の向上 ・ 保守性の向上 ・ 意思疎通の向上 等々、ちょっと考えただけでも色々出てきそうです。 なので、「オブジェクト指向はバグを減らす技術」っていうのは、確かに真かもしれないのですけど、それはひとつの側面に過ぎないんじゃないかな、と思いました。 以上、横槍というか、茶々でした。

>>バグを減らすにはどうすればいいかというと、極力コードを書き起こす量、 >>き換える量を減らすことです。 >>継承や多態性は抽象化のための手段であり、抽象化は再利用のための手段であり、 >>利用はコードを書く量を減らすための手段であると思います。 > >そこまで一般化してしまえばそうかもしれませんが。 それが悩みと言えば悩みで。 「オブジェクト指向はバグを減らすための技術である」は真であると思いますが、「バグを減らすための技術はオブジェクト指向である」これは偽です。 じゃあ「オブジェクト指向」という言葉の定義は何かというと、詰まってしまって… カプセル化も継承も多態性も「ソースコードを量を減らし、バグを減らすための手段である」と括ってしまうと、「バグを減らすための技術はオブジェクト指向である」が真になってしまうので。 「カプセル化を中核とし、それにバグ軽減のための様々な技法を付随させたものである」という定義を試みたこともありましたが、カプセル化だけ特別扱いするのもどうかと思いますし… >たとえば、interfaceを使うのと継承を使うのとでは、短期的には継承を使う方が >ソースは短くなるものですが、それでもinterfaceを使おう、というのが >最近の風潮ですし。 ただ闇雲にソースを短くすればいいというわけではありません。 そもそも、オブジェクト指向を使えば、どうしたってソースは肥大化すると思います。 一時的にはそうであっても、将来的に、トータルで見て書く量を減らそう、ということです。 >一例ですけど、StrutsのActionがinterfaceでなくクラスなのが気になって >しょうがないのです。私の場合。 Struts については（というか、Java 自体）よく知らないので、コメントは控えさせていただきます。

>これについては、 >「Smalltalk に端を発する、『オブジェクト同士のコミュニケーションは > メッセージパッシングだ』とする派と、C++ 流儀の『メッセージパッシングとは > 要するに関数呼び出しのことだ』とする派、２通りの『オブジェクト指向』が > 存在し、それがごっちゃになって受け取られているためだ」 そういうことなら、C++やJavaを使いたい人には、ことさらメッセージ云々と 説明するのは有害だということになりそうです。違う流儀なのですから。 >>すみません、ちなみにその本は何という本でしょうか。 >>よろしければ教えてください。 > >http://www.amazon.co.jp/exec/obidos/ASIN/4894711885/ あ、やっぱり。この本は読みました。 >バグを減らすにはどうすればいいかというと、極力コードを書き起こす量、 >き換える量を減らすことです。 >継承や多態性は抽象化のための手段であり、抽象化は再利用のための手段であり、 >利用はコードを書く量を減らすための手段であると思います。 そこまで一般化してしまえばそうかもしれませんが。 たとえば、interfaceを使うのと継承を使うのとでは、短期的には継承を使う方が ソースは短くなるものですが、それでもinterfaceを使おう、というのが 最近の風潮ですし。 一例ですけど、StrutsのActionがinterfaceでなくクラスなのが気になって しょうがないのです。私の場合。

レスありがとうございます。CES です。 >SDKでウィンドウプロシージャを書く人は、「メッセージ」のディスパッチを >特に苦労なく学べるんじゃないかと思っています。まあイベントドリブンへの >発想の転換は必要でしょうが、メッセージの受け渡しそのものは別に難しくない。 >Cの知識そのままでいけます。 >でも、「オブジェクト指向ではオブジェクト同士がメッセージを～」という >説明では混乱する人が出てくる。これは、「メッセージパッシングは >関数呼び出しとは異なるものだ」という説明があるせいだろうと思うわけです。 これについては、 「Smalltalk に端を発する、『オブジェクト同士のコミュニケーションはメッセージパッシングだ』とする派と、C++ 流儀の『メッセージパッシングとは要するに関数呼び出しのことだ』とする派、２通りの『オブジェクト指向』が存在し、それがごっちゃになって受け取られているためだ」 という記述を見つけました。 http://sumim.no-ip.com:8080/wiki/414 私は C++ 流しか知らないので、やはりオブジェクト指向の源流を理解するためには、Smalltalk（というか Simula？）を学ぶべきなのかな、と思います。 >>「オブジェクト指向で再利用性は高まるか?」 >> >>高まると思いますが、マルチプルインスタンスについて論じているらしい >>「こちら」のリンクが切れているので、先がすごく気になります… > >や、すみません。リンク先のURLにNOREFと書いてあるので、いずれ続きを書くつもり >だったんだろうと思います。 >で、当初書くつもりだったことは既に書いたつもりですので、 >おそらくこのリンク先は、 >http://kmaebashi.com/programmer/object/shigoto.html >ここのStringTokenizerあたりの説明のことを指しているのだと思います。 ># 既に忘却の彼方です。すみません。 了解いたしました。後ほど読ませていただきます。 >>まぁ、この Eiffel 本は「だから C++ はダメな言語だ。さぁ、皆で >>Eiffel を使おう！」とか言い出しそうな勢いですが。 > >すみません、ちなみにその本は何という本でしょうか。 >よろしければ教えてください。 http://www.amazon.co.jp/exec/obidos/ASIN/4894711885/ コイツです。 >私が書いたのは、「継承は、(ソースであれなんであれ)再利用の手段ではない」 >ということです。継承は抽象化の手段だと思っています。 「継承はコードを書かないための技術である」というのも、あながちハズレではない気がしています。 結局、オブジェクト指向とは何のために存在するのかというと、突き詰めれば「バグを減らすため」だと思います。 バグを減らすにはどうすればいいかというと、極力コードを書き起こす量、書き換える量を減らすことです。 継承や多態性は抽象化のための手段であり、抽象化は再利用のための手段であり、再利用はコードを書く量を減らすための手段であると思います。

どうも。はじめまして。 >しかし、それでも難しいという印象を持たれているのは、「どういうものか」は >頑張って説明するけれど、「どのようにありがたいのか」が伝わらないためでは >ないでしょうか。 そう思います。ていうかプログラミング言語はもちろん、プログラミングパラダイム まで含めても所詮「道具」に過ぎないわけで、道具なら、何の役に立つのかが わからなければならないはずです。 >「メッセージ」というと、ぱっと思いつくのが「（WM_CREATE などの）Window > メッセージ」ですが、Windows のアーキテクチャというのは、まさに > オブジェクト指向なのだと痛感させられます。 … >が、MFC なんぞ使わず SDK でウィンドウプロシージャを書いている人は、 >非オブジェクト指向言語を使っているんだなぁ、と思うと、何だか妙な気分です。 SDKでウィンドウプロシージャを書く人は、「メッセージ」のディスパッチを 特に苦労なく学べるんじゃないかと思っています。まあイベントドリブンへの 発想の転換は必要でしょうが、メッセージの受け渡しそのものは別に難しくない。 Cの知識そのままでいけます。 でも、「オブジェクト指向ではオブジェクト同士がメッセージを～」という 説明では混乱する人が出てくる。これは、「メッセージパッシングは 関数呼び出しとは異なるものだ」という説明があるせいだろうと思うわけです。 >「オブジェクト指向で再利用性は高まるか?」 > >高まると思いますが、マルチプルインスタンスについて論じているらしい >「こちら」のリンクが切れているので、先がすごく気になります… や、すみません。リンク先のURLにNOREFと書いてあるので、いずれ続きを書くつもり だったんだろうと思います。 で、当初書くつもりだったことは既に書いたつもりですので、 おそらくこのリンク先は、 http://kmaebashi.com/programmer/object/shigoto.html ここのStringTokenizerあたりの説明のことを指しているのだと思います。 # 既に忘却の彼方です。すみません。 >それは Eiffel が「外部から書き込み可能な public 変数」という概念を >持たないから言えることであって、その保護機能がない C++ では、 >変数を private にして getter のみ実装することは、Eiffel 風に言えば >「公開」であると思います。 もうひとつ重要なのは、Eiffelでは引数無しのメソッド呼び出しでは()が 不要だということですね。 >まぁ、この Eiffel 本は「だから C++ はダメな言語だ。さぁ、皆で >Eiffel を使おう！」とか言い出しそうな勢いですが。 すみません、ちなみにその本は何という本でしょうか。 よろしければ教えてください。 >> 継承は、ソースの再利用の手段ではないということです。 > >うーん…結局、ソース以外の何を再利用するんだろう、と思います。 >いや、言わんとすることはわかるんですが、突き詰めると、ソースの >再利用じゃん、と。 私が書いたのは、「継承は、(ソースであれなんであれ)再利用の手段ではない」 ということです。継承は抽象化の手段だと思っています。 >最後にひとつ、感じたことを言わせていただくと… >この再入門講座は「オブジェクト指向とは何であるか」ではなく >「オブジェクト指向とは何でないか」を説明していることが多いように >思えたのでした。 まあこれはそうでしょうねえ。 既存の説明について、ちょっとそれはないんじゃないか、というコンセプトで 書いてますから。

>１００ページの７および１０行目に出てくる macro.c というファイルは >４行目の cpp.c の書き間違いということで宜しいでしょうか。 書き間違いです。昔のことなのでさすがに記憶が曖昧ですが、このファイル名を cpp.cにするかmacro.cにするか迷っていて、最終的にはcpp.cにしたものの、 いくつか直し忘れがあった、ということだと思います。 こんなポカがいまだに残っているとは思いませんでした。 正誤表に追加しておきました。ご指摘ありがとうございました。 >なお当方の環境（Mac OS X 10.2.8 + gcc-3.1）で、cpp cpp.c と >gcc -E cpp.c を実行したところ以下のようになりました。 gcc -Eの方では、どうもCコンパイラが動いているように見えますね。 うちのgcc gcc (GCC) 3.4.2 (mingw-special) では再現していません。 Mac OS X をお持ちの方の情報をお待ちしております。

はじめまして。 なんか最近、自前のプログラミング言語を作りたくなって来たのであちこちフラフラしていて、こちらに流れ着きました。 「プログラミング言語を作る」のコーナーは、後ほどじっくり読ませていただきます。 さて、今回は一言「オブジェクト指向再入門」に物申させて頂きに参上仕りました。 文句ばっかりでなく、賛同とか感想の方が多いかもしれませんが… 「いい加減、わけのわからない「たとえ話」はやめよう」 賛成です。 この「わけのわからないたとえ話」というのは、「オブジェクト指向とはどういうものであるか」を、筆者なりに精一杯噛み砕いて説明しようとしたものだと思います。 しかし、それでも難しいという印象を持たれているのは、「どういうものか」は頑張って説明するけれど、「どのようにありがたいのか」が伝わらないためではないでしょうか。 「オブジェクトに「メッセージ」を送って…」 > 「メッセージ送出」と呼ばれているのは、たいていのオブジェクト指向言語では実のところ一種の関数呼び出しです。 重箱の隅を突っつくような指摘をお許しください。 オブジェクト指向で言うところの「メッセージ送出」が、大抵の（メジャーな）オブジェクト指向言語において「関数呼び出し」という形をとっているのは、確かにその通りです。 が、「オブジェクト指向」と「オブジェクト指向言語」は別のものであることは（非「オブジェクト指向言語」で「オブジェクト指向」を実現されている管理人様ならば）周知のことであると存じます。 「メッセージ」というと、ぱっと思いつくのが「（WM_CREATE などの）Window メッセージ」ですが、Windows のアーキテクチャというのは、まさにオブジェクト指向なのだと痛感させられます。 ウィンドウの原型を定義するウィンドウ「クラス」があり、個々のインスタンスであるウィンドウはそのクラスから作られ、振る舞いをカスタマイズしたい場合は「サブクラス化」し、「メッセージ」を送ると、同じメッセージであってもウィンドウごとに「多態的」な動作をする。 が、MFC なんぞ使わず SDK でウィンドウプロシージャを書いている人は、非オブジェクト指向言語を使っているんだなぁ、と思うと、何だか妙な気分です。 「オブジェクト指向で再利用性は高まるか?」 高まると思いますが、マルチプルインスタンスについて論じているらしい「こちら」のリンクが切れているので、先がすごく気になります… 「それは「カプセル化」なのか?」 > データ隠蔽ではなく実装隠蔽だ、という言葉があって、まあこれも > 言葉遊びの匂いがしないでもないですが、同様のことを言っているように > 思います。 （皆様からのご意見(2)より） そういう文句を、ある Eiffel 本で見ました。 確かに、C++ でいうクラスで private にするものには「そのクラスがカプセル化するデータ」と「実装のために必要なデータ」の２種類があり、これを区別することは有用であると思います。 が、この Eiffel 本は「データを隠蔽してしまったら誰も触れなくなる。データは公開せよ」というわけのわからんことを言います。 それは Eiffel が「外部から書き込み可能な public 変数」という概念を持たないから言えることであって、その保護機能がない C++ では、変数を private にして getter のみ実装することは、Eiffel 風に言えば「公開」であると思います。 まぁ、この Eiffel 本は「だから C++ はダメな言語だ。さぁ、皆で Eiffel を使おう！」とか言い出しそうな勢いですが。 「継承について」 > 継承は、ソースの再利用の手段ではないということです。 うーん…結局、ソース以外の何を再利用するんだろう、と思います。 いや、言わんとすることはわかるんですが、突き詰めると、ソースの再利用じゃん、と。 「オブジェクト指向言語によるサポート」 > こんなの見た目が変わっただけじゃないか! > 全くそのとおり。継承を考えない限りにおいては、オブジェクト指向言語といってもその程度のものです。 オブジェクト指向とは、ある日、何の前触れも無くぽっと生まれたものではなく、それ以前の歴史を脈々と受け継いだ上に、生まれるべくして生まれたものだと思います。 そして、「オブジェクト指向言語」とは、非オブジェクト指向言語よりもオブジェクト指向を「それっぽく書ける」だけの代物であって、正に「サポート」程度の役割しかないものだと思います。 オブジェクト指向の三本柱は「カプセル化」「継承」「多態性」だなんて、いったい誰が言ったんでしょうか。 結局のところ、（最初にも書きましたが）その三本柱が「何の役に立つのか」が見えないとダメなんだと思います。 C 言語で継承や多態性を実現するのは難しいですが、継承や多態性によって「何を成し遂げたいのか」がわかっているなら、きっと C でも素晴らしいプログラムが書けることでしょう。 もっと言ってしまうと、「オブジェクト指向」って、結局何なんだかよくわからなくなってきます。 おそらくそれは「オブジェクト思考」みたいなもんであって、「これ」というはっきりした形が無い「考え方」なんだと思います。 でも「じゃあ、その考え方に則っていればなんでもオブジェクト指向なのか」というとそんなことは無くて。…何なんでしょうね、オブジェクト指向って。 最後にひとつ、感じたことを言わせていただくと… この再入門講座は「オブジェクト指向とは何であるか」ではなく「オブジェクト指向とは何でないか」を説明していることが多いように思えたのでした。

『Ｃ言語体当たり学習徹底入門』（第２刷）を読み返していたときに気が付いたのですが、１００ページの７および１０行目に出てくる macro.c というファイルは４行目の cpp.c の書き間違いということで宜しいでしょうか。なお当方の環境（Mac OS X 10.2.8 + gcc-3.1）で、cpp cpp.c と gcc -E cpp.c を実行したところ以下のようになりました。これに関しては処理系の違いによるものと考えておいて良いのでしょうか。cpp.c と cpp.h は９９ページの例に従っています。 % cpp cpp.c | cat -n 1 # 1 "cpp.c" 2 # 1 "cpp.h" 1 3 hogehoge 4 hogehoge 5 hogehoge 6 # 2 "cpp.c" 2 7 8 9 10 hogehoge piyopiyo 100. % gcc -E cpp.c | cat -n cpp.h:1: undefined type, found `hogehoge' cpp.h:2: illegal external declaration, missing `;' after `hogehoge' cpp.c:5: undefined type, found `hogehoge' cpp.c:5: illegal external declaration, missing `;' after `piyopiyo' cpp-precomp: warning: errors during smart preprocessing, retrying in basic mode 1 # 1 "cpp.c" 2 3 # 1 "cpp.h" 1 4 hogehoge 5 hogehoge 6 hogehoge 7 # 1 "cpp.c" 2 /* 上の例と少し違います */ 8 9 10 11 12 hogehoge piyopiyo 100 .

>心ならずもトリガーになってしまった者として >一言お詫びさせて頂きます。 いやそんな、これはどうひっくり返っても竹内さんに責任があるような話では ありませんので、お気になさりませんよう。 >掲示板での(本来の)議論を楽しみにしておりますので、 >今後とも宜しくお願い致します。 私も最近むやみやたらと忙しく、更新が滞っておりましてすみません。 こちらこそ今後ともよろしくお願いいたします。

ヨルダンの竹内です。 最初の投稿以来、ちょっと忙しかった事もあり、掲示板を参照してませんでした。 その後の迷惑投稿について、私の最初の投稿が切っ掛けになっているらしい状況を知り、 何だか申し訳ない気持ちです。 >6/12 16:24 問題の書き込みがあった。「国際協力、掲示板」でGoogleして >　　　　　たどり着いた模様。 心ならずもトリガーになってしまった者として 一言お詫びさせて頂きます。 この手の不心得者は至る所に居て、やりきれない気持ちになりますが、 掲示板での(本来の)議論を楽しみにしておりますので、 今後とも宜しくお願い致します。

★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★ ★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★ ☆★☆ ★☆★　ライブチャット検索チャットレディ情報　無料ポータルサイト ☆★☆ ★☆★ ライブチャットひろば 　http://livechat-hiroba.com/ ☆★☆ ★☆★　ライブチャット人気サイトも、無料お試しサイトも、 ☆★☆　新規オープンも一目でわかる！ ★☆★　2005年の ライブチャットひろばでは、数あるライブチャットサイトを ☆★☆　独自の視点でて紹介しています！ ★☆★　サイト探しに苦労なさってるライブチャットファンの皆様に、 ☆★☆　少しでもお役に立てればと管理人が厳選したサイトをご紹介いたします。 ★☆★ また、出会い系サイトのご紹介や、相互リンクも随時募集しております。 ☆★☆　お気軽に御覧下さい。 ★☆★　もちろん無料で情報をゲットしてください。 ☆★☆　 ★☆★ ☆★☆ http://livechat-hiroba.com/ http://livechat-hiroba.com/

おお、ビンゴでしたか。 該当スレッドをいろんな形式で表示してみたり、 「PHP & MySQL」のコンテンツでデータ構造を調べたりして、 パズルを解くように推理して楽しんでました。 生データに手を入れて整合性を壊してしまうという落とし穴には私もよくハマります。 冗長なデータ構造(ここではmessage.top)をあえて導入している場合は特に注意が必要ですよね。 (ぱ)さんの掲示板は実用重視でシンプルに洗練されてますね。 お役に立てて何よりです。