K.Maebashi's BBS

オブジェクト指向再入門、とても面白く読ませていただきました。その中で ・手続き型言語を習得している「途中」の自分がどのようにオブジェクト指向を実践していけるのだろうか というところで疑問を抱いたので質問したいと思います。ここでのオブジェクト指向議論とは違う疑問なのかもしれませんが、書きたいと思います。 自分は、対象読者とされている「手続き型言語を習得し」た人ではないです。大学に入ってからプログラミングを習っています。使っている言語はDelphiです。 Delphiはオブジェクト指向言語ということだったのですが、学んでいるのは手続き型の勉強なのではないか、と感じました。そこからオブジェクト指向に興味を持ち、調べたもののこの再入門冒頭に書かれていたとおり、挫折しました。そして、もう一度と思っているところです。 いろいろなオブジェクト指向入門を見てきて、オブジェクト指向は ・大規模なプログラムの開発でないと効果を発揮しない ・プログラムを分割することが大切 ・デザインパターン（設計）を知らないといけない（？ という特徴を持っているのではないかと思っています。 そしてここのオブジェクト指向再入門で言っているマルチプルインスタンスというのは、Delphiのコードで言うと Type TStringList = class(TString); でTStringList型が出来て（これが「わけのわからない例え話」だったらすみません…） var Str1,Str2 : TStringList; というPrivate宣言をすることによって Str1 := TStringList.Create; Str2 := TStringList.Create; という具合に、同じ形のものを複数作成できる。そして、 Str1.hogehoge; Str2.hogehoge; というように、命令の主体を明らかにできる、ということが具体的な内容なのかなと考えています。 では、ここからが自分の疑問の核心なのですが、手続き型の学習の中で（あるいは小規模すぎるプログラムの中で）でもオブジェクト指向を実践する方法はないだろうか、ということです。 今自分が目をつけているのが、 ・「開放・閉鎖の原則(OCP:Open-ClosedPrinciple)」 というもので、これにのっとって実践を進めれば今ある機能を追加していくということでオブジェクト指向の利点を理解しやすく、かつ小さなプログラムを大きくしていけるのではないかと考えています。ここでの継承は、コードの再利用ではなく堅実なプログラムを組むため、という理由付けになりオブジェクト指向と呼べるのでは？と思っています。 しかしそのためには手続きを分節化し、プログラムを設計する能力がいるだろう、と思っています。 このような場合に、デザインパターンが有効なのだと思いますが、具体的にどうプログラムを組むのか、というところで自分は躓いている状況です。 しかし、上記のようなオブジェクト指向「初」入門が、オブジェクト指向言語から入った人には必要なのではないか、と思いました。再入門という観点からは不適切かもしれませんが、提起してみました。 乱文失礼いたしました。

はじめまして。 >いろいろなオブジェクト指向入門を見てきて、オブジェクト指向は > ・大規模なプログラムの開発でないと効果を発揮しない > ・プログラムを分割することが大切 > ・デザインパターン（設計）を知らないといけない（？ >という特徴を持っているのではないかと思っています。 デザインパターンはOOPの応用例であって、デザインパターンのためには OOPを知らないといけないけど、逆は真ではないのではないでしょうか。 GoFのパターンにはある意味マニアックなものもありますし。 >では、ここからが自分の疑問の核心なのですが、手続き型の学習の中で >（あるいは小規模すぎるプログラムの中で）でもオブジェクト指向を >実践する方法はないだろうか、ということです。 「小規模すぎる」というのがどの程度かわかりませんが、先に例に出した オセロや、以下のページにおいてあるドローツールなどは、趣味でも 十分作成可能な規模だと思いますがどうでしょうか。 ドローツール「X-Draw」のJavaアプレットによる実行例: http://kmaebashi.com/nazojava/xdraw/index.html サンプルソースはこちら: http://kmaebashi.com/nazojava/index.html >今自分が目をつけているのが、 > ・「開放・閉鎖の原則(OCP:Open-ClosedPrinciple)」 >というもので、これにのっとって実践を進めれば今ある機能を追加していくと >いうことでオブジェクト指向の利点を理解しやすく、かつ小さなプログラムを >大きくしていけるのではないかと考えています。 OCPというと、最近Matzにっき経由でこんなページを見つけましたが http://www.morijp.com/masarl/homepage3.nifty.com/masarl/article/dp-ocp-2.html ここの例だと音符クラスを使っていますね。 元祖MayerさんのOOSC(第1版)だと出版物(PUBLICIATION)クラスです。 上に挙げたX-Drawでは、Shape(図形)にdraw()メソッドを付けることで、 プログラムのあちこちにShapeの種類による分岐(Cならswitch case, Pascalなら case of文ですか)を書くことを避けることができ、図形の追加が容易にできるので、 これはまさに上のページやOOSCで挙げている例と合致していると思うのですが… ただ、ドローツール程度ではこれでよくても、実際大規模なCADなどでこういう 方法が使えるかといえば、 ・draw()といっても、ウインドウシステム等の違いにより描画方法は異なる。 　ディスプレイリストを保持するシステムを使うなら、そもそも描画はdraw()じゃないぞ。 ・Shapeだからといってdraw()するとは限らない。データをファイルから 　読み込んで解析だけして結果をテキストファイルに吐くようなツールだってあるぞ。 という問題もあるわけでして(あっちこっちに書いてるネタですが)。 結局設計に万能の「正解」はなく、たとえば拡張に備えるにしても「どんな拡張が ありそうか」ということをある程度予測してからでないと設計方針は選べないんじゃ ないかなあ、と思います。つまらない結論かもしれませんけど。 >ここでの継承は、コードの再利用ではなく堅実なプログラムを組むため、 >という理由付けになりオブジェクト指向と呼べるのでは？と思っています。 そうですよね。実のところ私はconcrete classなんざ継承できなくても よいのでは、と思っていますが、上で出ている例(Note, PUBLICICATION, Shape)は どれも抽象クラスですし、使用範囲を間違えなければ、有効に使えると思います。

こんにちは。 >いろいろなオブジェクト指向入門を見てきて、オブジェクト指向は > ・大規模なプログラムの開発でないと効果を発揮しない > ・プログラムを分割することが大切 > ・デザインパターン（設計）を知らないといけない（？ >という特徴を持っているのではないかと思っています。 私は、上記のどれもオブジェクト指向の特徴を表していないと 思います。 以前ここの掲示板でオブジェクト指向のポイントは、以下の ２点であるという結論になっていたと思います。 1. データの抽象化 2. マルチプルインスタンス 何ができれば、オブジェクト指向になるのかは難しいと思いますが、 上記の２点はオブジェクト指向を語る上で重要だと思います。 あと、データのアクセス制御(制限？)なども重要だと思っています。 >では、ここからが自分の疑問の核心なのですが、手続き型の学習の中で（あるいは小規模すぎるプログラムの中で）でもオブジェクト指向を実践する方法はないだろうか、ということです。 > >今自分が目をつけているのが、 > ・「開放・閉鎖の原則(OCP:Open-ClosedPrinciple)」 >というもので、これにのっとって実践を進めれば今ある機能を追加していくということでオブジェクト指向の利点を理解しやすく、かつ小さなプログラムを大きくしていけるのではないかと考えています。ここでの継承は、コードの再利用ではなく堅実なプログラムを組むため、という理由付けになりオブジェクト指向と呼べるのでは？と思っています。 > >しかしそのためには手続きを分節化し、プログラムを設計する能力がいるだろう、と思っています。 >このような場合に、デザインパターンが有効なのだと思いますが、具体的にどうプログラムを組むのか、というところで自分は躓いている状況です。 私は普段オブジェクト指向言語を使用していないのですが、 オブジェクト指向を意識したプログラミングをしています。 小規模であっても、手続き型言語であってもオブジェクト指向的 発想は可能です。 例えば、GUIのいくつかのパーツがあって、これらが互いに依存しあう 場合、これら同士でお互いを直接呼び出さないようにします。 必ず親(Mediator)を作って、間接的に制御します。 こうすることで、依存関係を親側に集中化でき、単純化できます。 これの本質部分は、全くオブジェクト指向は関係ありません。 GUIパーツ自身は、本来自分がやるべきことのみ やらせるようにします(単一責任の原則)。 あと、OCPにより、小さなプログラムを大きくしていける (コードを再利用する)というのは、私はそんなに単純ではない と思います。 OCPとは、つまり、上側のコードの再利用であり、下側の コード(処理やデータなど)を追加のみするということですが、 それが、そんな単純にうまくいくなら、トップダウンの 開発が重要ということになります。 仕様変更によるプログラムへの影響は多くが、より上側の処理 であり、より下側の処理の方が再利用の確率は高いと 思います。 プログラムを大きくしていく秘訣はいかにプリミティブな 関数など(より下側の処理)を充実していくかとか、 いかにモジュール化により、プログラムを分割していくかに よると思います。 そもそもOCPは、オブジェクト指向言語だけでは不十分で、 例えば、ログの処理やエラー処理が入ると それだけで処理の「汎用性」が失われ、OCPが成立しません (例えば、エラーを出すタイミングを変えるなど)。 アスペクト指向言語があれば十分かは分かりませんが、 あらかじめ仕様変更を予想してOCPが成立するように 再利用可能なコードを組むのは現実的には不可能だと思います。 但し、局所的に(場合によって)は、うまくいく時ももちろんあります。

オブジェクト指向を学ぶには、２つのアプローチがあると思います。 ひとつは技術面から、もうひとつは論理面からです。 技術面からというのは、よく言われている「クラス、継承、カプセル化、多態性、OCP」などのキーワードから理解していく方法です。実装面からのアプローチとも言えます。 プログラムをいかにうまく分割し、個々の保守性を上げるかという点が重要です。 論理面は、思想面とも言えるかもしれません。 例えば、「クラス」という用語の意味は「分類」であって、「原型」ではありませんから、「クラスからオブジェクトを作る」という言い方はおかしいのです（実装面からの理解であれば問題ありません）。 オブジェクトは作るのではなく、既にこの現実世界に存在しているのです。それを抽象化して、分類したものがクラスであるというのが、この考え方の第一歩ではないかと思われます。 こっちの考え方は、突き詰めると数学や論理学の知識が必要になってしまうので、実装面ほど簡単ではありません（私も勉強したいのですが、それらベースとなる知識が足りないため足踏みしています）。 技術面の方がわかりやすいのですが、論理面を知らないと、オブジェクト指向の真髄を知っているとは言えないと思います（技術面だけ理解してオブジェクト指向を知った気になっていると、失敗すると思います）。そして、論理面がわかってくると、技術面が、すとんと胸に落ちるように理解できるようになるのではないでしょうか。 オブジェクト指向がこれだけ流行っているのですから、論理面からの入門ももっとあっていいと思うんですけどね…。

>例えば、「クラス」という用語の意味は「分類」であって、「原型」では >ありませんから、「クラスからオブジェクトを作る」という言い方は >おかしいのです（実装面からの理解であれば問題ありません）。 たとえばUMLだと、「継承」という言葉よりも「汎化」という言葉を使いますよね。 クラスという言葉の辞書的な定義はともかく(単に用語が不適切であるという可能性も あるので)、分析レベルでは、確かに「分類」と捉えたほうがよいのかもしれません。 >こっちの考え方は、突き詰めると数学や論理学の知識が必要になってしまうので、 >実装面ほど簡単ではありません（私も勉強したいのですが、それらベースと >なる知識が足りないため足踏みしています）。 ただ、そっち方面を突き詰めると、たとえば(よくある例ですが) 「円と楕円はどっちがスーパークラスか?」という問題で間違った解を選んで しまいそうな気もします。 数学や論理学の世界では、円は楕円の特殊形ですが、だからといってCircleを Ellipseのサブクラスにすることが妥当とは思えません(ただ、メンバが増えている からといって、EllipseをCircleのサブクラスにするのが適切とも思えません)。 実装面べたべたで行くと、抽象度の高い設計ができずに後ではまるといった 問題があるのかもしれませんが、実装を離れて理論で突っ走っても、結局変なことに なってしまうように思います。月並みですがバランスが大事、ということでしょうか。

>「円と楕円はどっちがスーパークラスか?」という問題で間違った解を選んで >しまいそうな気もします。 >数学や論理学の世界では、円は楕円の特殊形ですが、だからといってCircleを >Ellipseのサブクラスにすることが妥当とは思えません(ただ、メンバが増えている >からといって、EllipseをCircleのサブクラスにするのが適切とも思えません)。 「真実は人の数だけある」とか、よく言われますよね。 唯一不変の真理なんてものはどこにも無くて、人によって「それをどう見れば都合がいいか」というのが違うわけです（大勢にとって都合がいいことが真理だと勘違いされがちですが…）。 何が言いたいかというと、「円は楕円のサブクラスである」というのは、そうであったほうが都合がいい場合にのみ、真実となるわけです。オブジェクト指向では、よく「正方形は長方形のサブクラスである」という話が問題になりますが、これも同様ですね。 我々の日常でも「リンゴは果物のサブクラスである」というのは一面の真実ですが、唯一の真理ではありません（植物学者には「リンゴはバラ科のサブクラスである」の方が都合がいいでしょうし、スーパーでは「リンゴは商品のサブクラスである」のほうが都合がいいでしょう。これらはどれも真実です）。 客観的な視点などというものは存在しません。 「Circle を Ellipse のサブクラスにすることが妥当と思えない」のはひとつの真実ですが、絶対の真理ではありません。Circle を Ellipse のサブクラスにすることが適切な場合もあります。どちらも正解で、間違いは名探偵のように「真実はいつもひとつ！」だと思うことです。

えっと、前橋さんとCESさんと結局同じこといってるようにしか見えないのですが気のせい？ >月並みですがバランスが大事 >「それをどう見れば都合がいいか」 今、やってる案件においてどう設計すれば適切か、バランスとか都合よさとかから決めろ としか読めん。 だから私は「再利用性」って奴にはかなり疑問。 案件Ａにおいては今書いたコードが適切であっても、それは案件Ｂでは通用しない ってのはごく普通にありそうですし。 >「真実はいつもひとつ！」 いや、真実はいつもひとつです（と、俺は思う）。 その真実ってのは、人に理解できるような代物ではなかったりすることもある。 だから、個々人で理解の仕方が違うってのは普通の話。 どの角度から見るかで見え方＝コードの実装が異なるだけです。 同じ真実を違う角度で見れば、違うコードになる。ってただそれだけと思う。

> えっと、前橋さんとCESさんと結局同じこといってるようにしか見えないのですが気のせい？ > >> 月並みですがバランスが大事 >> 「それをどう見れば都合がいいか」 > 今、やってる案件においてどう設計すれば適切か、バランスとか都合よさとかから決めろ > としか読めん。 たぶん違うこと言ってる。 前橋さんは > 分析レベルでは、確かに「分類」と捉えたほうがよいのかもしれません とも言われているけれど、俺がしている話はどれも分析レベルだったんだ。と、今更気づく。 そこから一段階進んだ「設計」の段階では、確かにバランスが大事。 [653] のレスをつけたのは「円を楕円のサブクラスにすることが間違いとは限らないよ」って言いたかったから。 > 「円と楕円はどっちがスーパークラスか?」という問題で間違った解を選んでしまいそうな気もします。 > 数学や論理学の世界では、円は楕円の特殊形ですが、だからといってCircleをEllipseのサブクラスにすることが妥当とは思えません。 少なくとも、この問題文だけを見て、「円が楕円のサブクラスであるのは間違いだ」とは言えない、ということ。 「常に」という言葉を補って、「Circle を Ellipse のサブクラスにすることが『常に』妥当とは思えません」ということならば、それは正解。 >だから私は「再利用性」って奴にはかなり疑問。 >案件Ａにおいては今書いたコードが適切であっても、それは案件Ｂでは通用しない >ってのはごく普通にありそうですし。 でも、案件Ａで今書いたコードが、案件Ａ ver2 でも有効なことはすごく大切。それもひとつの再利用性。 >>「真実はいつもひとつ！」 >いや、真実はいつもひとつです（と、俺は思う）。 >その真実ってのは、人に理解できるような代物ではなかったりすることもある。 >だから、個々人で理解の仕方が違うってのは普通の話。 ひとつしかないのは「事実」だと思う。 それをどう見るかが「真実」。 でも、「真実」という言葉が「人によって違うもの」という意味に合致するかどうかはどうでもいい（というか、自分でもそういう意味なのかは疑問）。 ただ、「真実は人の数だけある」ってよく聞くから、その言葉を使っただけで、「普遍的に正しいものは無いんだよ」ってことが伝わるなら、「真実」って言葉にこだわる必要はない。

そして、[651] をちょっと補足。 >>こっちの考え方は、突き詰めると数学や論理学の知識が必要になってしまうので、 >>実装面ほど簡単ではありません（私も勉強したいのですが、それらベースと >>なる知識が足りないため足踏みしています）。 >実装面べたべたで行くと、抽象度の高い設計ができずに後ではまるといった >問題があるのかもしれませんが、実装を離れて理論で突っ走っても、結局変なことに >なってしまうように思います。月並みですがバランスが大事、ということでしょうか。 設計段階においてはその通りです。 ただ、ソフトウェアは「設計」「実装」の２段階ではなく、その前に「分析」を加えた３段階で作られます。そして、（本来は）分析なくして設計はなく、設計なくして実装はありえません。 実装の方が触るのは容易なので、実際には「実装→設計→分析」とスキルアップしていくケースが多いのでしょうか。 たぶん「分析」ができないと、オブジェクト指向の真髄を知ったとは言えないだろうなぁ、と思うわけです（実装だけ知っていれば、「オブジェクト指向プログラミング」は極められるかもしれませんが、「オブジェクト指向」を極めるにはそれだけでは足りません）。 当初のタイトルは『オブジェクト指向「初」入門』ですが、これはつまり『オブジェクト指向プログラミング「初」入門』ということですよね。 分析入門もあればいいのになぁ…と思いつつ、最近こんな本を読んでいたり。 http://www.sra.co.jp/people/aoki/IntroductionToOOAOOD/ ただ、「分析」を行うには、論理学を知っていたほうがいいのはあるかもしれませんが、[651] で意図したのはそういうことではありません。 「オブジェクト指向」そのものの数学的、論理学的意味についてです。 たとえば、クラスは分類だと言いましたが、数学的に言えば、クラスはオブジェクトの集合です。派生クラスは部分集合で、多重継承は積集合で…なんて数学の知識は、実務では分析レベルでもそうそう必要ない気がします。 もっと突っ込むと、群論とか圏論といった、ムズカシイ数学が出てきます（勉強したいのですがさっぱりわかりません）。 ちなみに、圏論には「オブジェクト」「クラス」「モルフィズム」というような用語が登場します。…なんとなくオブジェクト指向チックですよね？ こういう方面から攻めるのも併用すると、より理解が深まるんじゃないかな、ってことです。

もう全面的に御意。 分析→設計→実装、の段階のどこのレベルで話をするかがきわめて大事。 >でも、案件Ａで今書いたコードが、案件Ａ ver2 でも有効なことはすごく大切。それもひとつの再利用性。 ここんところ、鼻血が出るほど御意。 幸い今までのところ ver2 で設計見直しになった例は（俺の担当範囲では）まだないので 「ＯＯって何」に対する俺の理解はそう外れてはいないのだと思われ。 分析→設計のレベルの話を後輩君にするときにはこういう例を出してる。 class bird { virual void fly()=0; }; という設計においては「こうもりは鳥」であるし「ダチョウは鳥でない」 「こうもりは鳥でない」「ダチョウが鳥である」にしたいのなら、先の設計は変。 設計を見直す＝分析のしなおし、だよん。って。

>何が言いたいかというと、「円は楕円のサブクラスである」というのは、 >そうであったほうが都合がいい場合にのみ、真実となるわけです。 まったく同意です。私が言いたかったのは、「数学や論理学の世界」を突き詰めると、 円は楕円のサブクラスである、というのを、絶対の真実として突き進んでしまう 危険があるのではないか、ということです。 >「Circle を Ellipse のサブクラスにすることが妥当と思えない」のは >ひとつの真実ですが、絶対の真理ではありません。Circle を Ellipse の >サブクラスにすることが適切な場合もあります。 まあそうかもしれません。(私にはそういう状況が思いつかないというだけで) その意味では、「だからといってCircleをEllipseのサブクラスにすることが 妥当とは思えません」と書いたのは不用意だったかもしれませんね。

>分析→設計→実装、の段階のどこのレベルで話をするかがきわめて大事。 そう思います。 私は、ビーム砲の弾からインベーダーへの関連を持つというモデルを正解として 紹介していることをもって「憂鬱なプログラマのためのオブジェクト指向開発講座」を 批判していますが、「分析」のレベルなら、ビーム砲の弾からインベーダーへ 線を引っ張るのもよいのかもしれません。実際、そういう文脈で、私も文章を 批判している記事は見たことがあります。 インベーダーゲームにおいて、ビーム砲の弾がインベーダーを破壊するのは 確かですから、ここに線を引っ張るのは、客先の業務でありがちな「暗黙知」を 明確にするという意味では意味があるのかもしれません。 …が、憂鬱本の場合、「クラスのメンバに相手クラスのポインタを持つということで 実際に関連を張るわけです」と明言している点で、これは完璧に実装の本であり、 結局憂鬱本がトンデモ本であるという評価に揺らぐところはないわけですけど。

＃話が脇にそれてたので源流復帰。 > ・大規模なプログラムの開発でないと効果を発揮しない どの程度のことを「大規模」と言うかわかりませんが、オブジェクト指向が適用できない（適用する必要が無い）ほど小規模なものとなると、せいぜい 50 行…いや、20 ～ 30 行程度のプログラムになってしまうかなー、と。 > ・プログラムを分割することが大切 ＹＥＳ。それすげぇ大切。 > ・デザインパターン（設計）を知らないといけない（？ 知っていて損はないけれど、必須ではないと思う。俺も知らないし。 >そしてここのオブジェクト指向再入門で言っているマルチプルインスタンスというのは オブジェクト指向の一番の基礎はカプセル化です。 カプセル化ってのは、「データと処理をペアにして、このペアを最小単位として考える」ことです。 マルチプルインスタンスってのは、このペアがいっぱいあることです。 >では、ここからが自分の疑問の核心なのですが、手続き型の学習の中で（あるいは小規模すぎるプログラムの中で）でもオブジェクト指向を実践する方法はないだろうか、ということです。 目的が良くわかんないです。 まず、「オブジェクト指向」と「手続き型」は対立しません。 現在主流のオブジェクト指向言語は、手続き型言語に、オブジェクト指向のサポートを加えたものです。 ですから、「手続き型の中でオブジェクト指向を実践」するということは、立派にオブジェクト指向です。 「手続き型の中でオブジェクト指向を実践」とは、どんなことを意図されて書かれたのでしょう？ > ・「開放・閉鎖の原則(OCP:Open-ClosedPrinciple)」 これは「よりよいオブジェクトの設計のための指針」なので、初歩でまず覚えるべきことではないような気がします。 >しかしそのためには手続きを分節化し、プログラムを設計する能力がいるだろう、と思っています。 これはオブジェクト指向でなくとも、多かれ少なかれ必要な能力です。 >このような場合に、デザインパターンが有効なのだと思いますが、具体的にどうプログラムを組むのか、というところで自分は躓いている状況です。 別の掲示板で、素晴らしい言葉を見つけました。この言葉を送ります。 Good judgement comes from experience, and experience comes from bad judgement. （よい判断は経験から来ます。また、経験は悪い判断から来ます。 ） Experience is a wonderful thing. It enables you to recognize a mistake when you make it again. （経験は素晴らしいものです。再びそれを作る場合、それによって誤りを認識することができます。） まぁ、最初のうちはわからないなりに模索して失敗してみろって事ですね。 そのうち、だんだんとありがたみがわかってくると思います。

>結局設計に万能の「正解」はなく、たとえば拡張に備えるにしても「どんな拡張が >ありそうか」ということをある程度予測してからでないと設計方針は選べないんじゃ >ないかなあ、と思います。つまらない結論かもしれませんけど。 「分析」→「設計」→「実装」の流れで言うならば、万能の唯一解がないのは「分析」でしょうね。 分析が正しくできていれば、正しい設計はおのずと導かれる気がします。 >そうですよね。実のところ私はconcrete classなんざ継承できなくても >よいのでは、と思っていますが、上で出ている例(Note, PUBLICICATION, Shape)は >どれも抽象クラスですし、使用範囲を間違えなければ、有効に使えると思います。 concrete class って何なのか、参考までにお聞きしてもよろしいでしょうか。 「クラスとは分類である」という考えをすると、具体的なものはオブジェクトで、クラスは全て抽象的なものということになるからです（その点、「抽象クラス」ってのは良くないネーミングだと思います）。 ＃実装の再利用のためのクラスはクラスである意味が薄いと思いますし。

>以前ここの掲示板でオブジェクト指向のポイントは、以下の >２点であるという結論になっていたと思います。 >1. データの抽象化 >2. マルチプルインスタンス >何ができれば、オブジェクト指向になるのかは難しいと思いますが、 >上記の２点はオブジェクト指向を語る上で重要だと思います。 >あと、データのアクセス制御(制限？)なども重要だと思っています。 アクセス制限は抽象化の範疇だと思います。

>class bird { virual void fly()=0; }; >という設計においては「こうもりは鳥」であるし「ダチョウは鳥でない」 これはすごく面白い。深いなぁ。

>concrete class って何なのか、参考までにお聞きしてもよろしいでしょうか。 通常の定義では、abstractでないクラスがconcrete classでしょう。 Googleしてもいっぱい出ますし。 >「クラスとは分類である」という考えをすると、具体的なものはオブジェクトで、 >クラスは全て抽象的なものということになるからです（その点、「抽象クラス」 >ってのは良くないネーミングだと思います）。 それはそうかもしれませんけど、具体的なオブジェクトにできないものが 抽象クラスで、具体的なオブジェクトを作れるものがconcrete classってのは、 それほど無理はないんじゃないでしょうか。 たとえば「スーパー」クラスの方が「サブ」クラスよりへぼいってのも直感には 反しますよね。術語は所詮術語なので、あんまり厳密性を求めてもしょうがない 気がします。

>>concrete class って何なのか、参考までにお聞きしてもよろしいでしょうか。 > >通常の定義では、abstractでないクラスがconcrete classでしょう。 >Googleしてもいっぱい出ますし。 やっぱりそれですか。 それでいくと、継承できないと問題が出そうな気もしますけど…まぁそれは置いといて。 >それはそうかもしれませんけど、具体的なオブジェクトにできないものが >抽象クラスで、具体的なオブジェクトを作れるものがconcrete classってのは、 >それほど無理はないんじゃないでしょうか。 現状、そのような用法で広く使われておりますので、あえてそれに反旗を翻すような真似はいたしませんです。 ＃自分で言語を作ったら別の呼び方にしたいけれど。 >たとえば「スーパー」クラスの方が「サブ」クラスよりへぼいってのも直感には >反しますよね。術語は所詮術語なので、あんまり厳密性を求めてもしょうがない >気がします。 集合の「スーパーセット」と「サブセット」に対応すると考えれば、じつにしっくり来るです。 「上位クラス」「下位クラス」というネーミングも、上の方がショボい気がしてよろしくないですね。 C++ 流儀の「基底クラス」は、スーパーの方が下のように聞こえるので直感的？ ただ、機能に注目するとサブクラスの方が多いんですが、スーパーの方が「範囲が広い」という点は優位ですね。

>>たとえば「スーパー」クラスの方が「サブ」クラスよりへぼいってのも直感には >>反しますよね。術語は所詮術語なので、あんまり厳密性を求めてもしょうがない >>気がします。 > >集合の「スーパーセット」と「サブセット」に対応すると考えれば、じつにしっくり来るです。 >「上位クラス」「下位クラス」というネーミングも、上の方がショボい気がしてよろしくないですね。 >C++ 流儀の「基底クラス」は、スーパーの方が下のように聞こえるので直感的？ >ただ、機能に注目するとサブクラスの方が多いんですが、スーパーの方が「範囲が広い」という点は優位ですね。 クラスはオブジェクトの集合なのだから、上下関係ではなくて包含関係で見るべき。 だとすれば、「サブクラスがヘボい」んじゃなくて「スーパークラスもサブクラスも同じ機能を持っているんだけど、スーパークラスではその一部に言及されていないだけ」なのだから、機能の比較はできなくて、広さで優位に立つスーパークラスの方がすごい。 こういうところも、論理面から攻めると違和感を無くすことができました、という例。

>＃自分で言語を作ったら別の呼び方にしたいけれど。 では言語を作ることをお勧めしますです。 # と思って「プログラミング言語を作る」を続けてるわけですが。 でも、たとえばcrowbarではオブジェクトの要素を「メンバ」と呼んでいますが、 JavaScriptあがりの人があれをプロパティと呼んだり、Selfとかあがりの人が スロットと呼ぶことを妨げようとは思いません。「crowbarにはプロパティはない」とか 言い始めたら、そりゃトンデモです。 だからもちろんJavaにはポインタが…すみません脱線しすぎました。 >集合の「スーパーセット」と「サブセット」に対応すると考えれば、 >じつにしっくり来るです。 この議論は昔JavaHouseでやったことがあるんですが、その時は 「スーパーサイヤ人」がネタに出ましたね。集合で考えればふつうのサイヤ人が スーパーサイヤ人のスーパーセットです(悟飯やトランクスは混血だけど…)。 集合で考えれば確かにそうなんだけど、「スーパーサイヤ人」の方がスーパーだ、 という言葉の使い方も確実にあるわけで、そこに違和感を覚えてることも そりゃあるんじゃないかと。 >C++ 流儀の「基底クラス」は、スーパーの方が下のように聞こえるので直感的？ Straustrupは、そこに違和感を感じたから基底クラス(base class)という言葉にした、 という話を聞いたことがありますが、確か2chで読んだ話だと思うので信憑性は 定かではありません。

>「スーパーサイヤ人」がネタに出ましたね。集合で考えればふつうのサイヤ人が >スーパーサイヤ人のスーパーセットです(悟飯やトランクスは混血だけど…)。 >集合で考えれば確かにそうなんだけど、「スーパーサイヤ人」の方がスーパーだ、 >という言葉の使い方も確実にあるわけで、そこに違和感を覚えてることも >そりゃあるんじゃないかと。 ＃言うまでもないことだとは思うのですが。 「スーパーサイヤ人」と、そのスーパーセットである「サイヤ人」では、どっちがすごいか…というのは比べられません。 「スーパーサイヤ人」と「ノーマルサイヤ人（？）」なら、スーパーサイヤ人の方がすごいですが、これはどちらも「サイヤ人」のサブセットです。 「サイヤ人＝ノーマルサイヤ人」でないところが罠ですね。違和感の元はここかと。

>>「スーパーサイヤ人」がネタに出ましたね。集合で考えればふつうのサイヤ人が >>スーパーサイヤ人のスーパーセットです(悟飯やトランクスは混血だけど…)。 >>集合で考えれば確かにそうなんだけど、「スーパーサイヤ人」の方がスーパーだ、 >>という言葉の使い方も確実にあるわけで、そこに違和感を覚えてることも >>そりゃあるんじゃないかと。 > >＃言うまでもないことだとは思うのですが。 >「スーパーサイヤ人」と、そのスーパーセットである「サイヤ人」では、どっちがすごいか…というのは比べられません。 >「スーパーサイヤ人」と「ノーマルサイヤ人（？）」なら、スーパーサイヤ人の方がすごいですが、これはどちらも「サイヤ人」のサブセットです。 >「サイヤ人＝ノーマルサイヤ人」でないところが罠ですね。違和感の元はここかと。 この違和感が「集合論で考えればわかりやすいね」で解決しなくて「いや、どうしても直感的に受け入れられない」ってことだとすると、オブジェクト指向を集合論で考えちゃいけねぇってことになる。それはいくらなんでも横暴じゃないかなぁ…数学を全部敵に回しそうだ。

こんばんは。前回は、はじめてであるのに名乗らずに失礼しました。 自分が浅学なのを暴露してしまうような気がしますが…こういう理解でいいのかな、と 少し確認の意味で書いてみます。 ＣＥＳ さん： >どの程度のことを「大規模」と言うかわかりませんが、オブジェクト指向が適用できない（適用する必要が無い）ほど小規模なものとなると、せいぜい 50 行…いや、20 ～ 30 行程度のプログラムになってしまうかなー、と。 まさにその程度のプログラムにおいて、そしてそこから大きくしていく過程において、のこと を自分は想定していました。 for文やif文の学習という過程から、だんだんと大きなプログラムを組んでいく場合において、 オブジェクト指向をうまく取り入れられないかな、と考えたわけです。 >> ・プログラムを分割することが大切 > >ＹＥＳ。それすげぇ大切。 この部分で、前にタイガーさんがおっしゃっていた >こうすることで、依存関係を親側に集中化でき、単純化できます。 というようなことを実現するために、分割が必要になってくるのだ、と自分は理解しています。 しかし、これだとサブルーチンという考え方だけで大丈夫だという記述もあり、どのように コードを組めばオブジェクト指向プログラミングとなるのか、というところが未だに自分の 中で曖昧になってしまっています。 いろいろなオブジェクト指向入門で見た「コードの再利用」というのも、なんだか疑わしい と思っています。継承することによって再利用というのがしっくりこなかったです。そこで デザインパターンから継承の利点などを見つけれればと思いましたが、自分にはまだ荷が 重かったようでした。 >目的が良くわかんないです。 >まず、「オブジェクト指向」と「手続き型」は対立しません。 >現在主流のオブジェクト指向言語は、手続き型言語に、オブジェクト指向のサポートを加えたものです。 >ですから、「手続き型の中でオブジェクト指向を実践」するということは、立派にオブジェクト指向です。 > >「手続き型の中でオブジェクト指向を実践」とは、どんなことを意図されて書かれたのでしょう？ いろいろな人がオブジェクト指向プログラミングの特徴について書いていますが、 オブジェクト指向プログラミングは、堅牢なコードを書いていく技術であり、そのために データの抽象化や、マルチプルインスタンス（これは堅牢なコードのためじゃないかも しれませんが）があるのかな、と思っています。 そのなかで、技術的なアプローチから入っていこう、とした場合に、まず何を理解して 実践すればいいのかが、現在のオブジェクト指向ではまったくといっていいほど分からない のでは、と思った次第です。 確かに、「再」入門の人々にとっては当たり前なのかもしれませんが、「初」入門の 人にとっては、ということです。（ということで、この質問はかなりこの掲示板の趣旨 からは離れているのかな、と思います。しかし、「初」入門の自分がいろいろな入門を 見てきた中で、一番しっくりきたのがこの「再」入門であったので、何かしらそういう 視点からの助言が得られるのでは…と思い、提示しました（大変参考になりました）。） >まぁ、最初のうちはわからないなりに模索して失敗してみろって事ですね。 >そのうち、だんだんとありがたみがわかってくると思います。 ということなので、今自分が実践できることは、プログラムを分割して、単一の仕事 だけをさせるようにし、責任の所在を分かりやすくしてみることかな、とおもいます。 そして、これから挑戦していくものとして、（ぱ) さんがおっしゃっていた >上に挙げたX-Drawでは、Shape(図形)にdraw()メソッドを付けることで、 >プログラムのあちこちにShapeの種類による分岐(Cならswitch case, Pascalなら >case of文ですか)を書くことを避けることができ、図形の追加が容易にできるので、 >これはまさに上のページやOOSCで挙げている例と合致していると思うのですが… という部分から、if文やcase文を使わないですむコードを書いてみたいと思っています。 具体的すぎる話だけだと、抽象度の高い設計ができないということなので、 データの抽象化というものを具体的にコードにできるようにしたいと思っています。 やってみて考えてみて、経験から分かってくるというのが唯一の正解である、という のは理解できるのですが、具体的にこういう学習をしてみようと思っていると書くこと によって、自分の進んでいるのがオブジェクト指向なのか、それとも間違っているのか について助言が得られたらな、と思っています。

>この違和感が「集合論で考えればわかりやすいね」で解決しなくて「いや、どうしても直感的に受け入れられない」ってことだとすると、オブジェクト指向を集合論で考えちゃいけねぇってことになる。それはいくらなんでも横暴じゃないかなぁ…数学を全部敵に回しそうだ。 　私が最初から言っているのは、「術語に過剰な期待をするのはいかがなものか」ということです。 　集合論で見て、サイヤ人はスーパーサイヤ人のスーパーセットですが、やっぱりスーパーサイヤ人の方に「スーパー」が付いている。そういう言葉の使い方が現実にある以上、「スーパークラス」という言葉に違和感を感じる人もそりゃいるだろうねえ、と言っているだけです。 　いつ私が「オブジェクト指向を集合論で考えちゃいけねぇ」と言いましたか? 言っていると思うのなら、その部分を具体的に引用して示してください。 　んで、集合論で考えるなら円は楕円のサブセットなのであって、それを「客観的な視点などというものは存在しません」などと言って否定してしまったら、それこそ数学を全部敵に回すと思うんですが、如何?

>まさにその程度のプログラムにおいて、そしてそこから大きくしていく過程において、のこと >を自分は想定していました。 >for文やif文の学習という過程から、だんだんと大きなプログラムを組んでいく場合において、 >オブジェクト指向をうまく取り入れられないかな、と考えたわけです。 思うのですが、オブジェクト指向は目的ではなく手段なのだから、 for文やif文の学習という過程から、だんだんと大きなプログラムを組んでいく 場合において、「このままでは破綻する」という状況がオブジェクト指向でうまく 回避できる、というのが想像できればよいのではないでしょうか。 ま、とはいえ世の中には「5000行の関数」を書いてしまうツワモノもいるわけで、 力技でもできる奴(どういう意味で「できる」かはアレですが)はやってしまうという のもあります。実際、5000行はともかく数百行程度なら、どんな書き方をしていても なんとかなってしまう、という面はあります。では一万行に挑んで痛い目に遭ってみれば オブジェクト指向のありがたみがわかるのかというと…そうなのかもしれませんが、 それでは痛い目に遭うためのコストが大きすぎますよね。 そのあたりは、「この方法では、もっと規模が大きくなったときどうなるだろう?」と 想像力で補うのがよいのではないかと思います。 >しかし、これだとサブルーチンという考え方だけで大丈夫だという記述もあり、 サブルーチンで大丈夫な範囲ならサブルーチンで大丈夫。 オブジェクト指向の方がよいのなら、サブルーチンに比べて「どこがどうよいのか」が 説明できなければならない、というのが私の言いたかったところです。 >いろいろなオブジェクト指向入門で見た「コードの再利用」というのも、なんだか疑わしい >と思っています。継承することによって再利用というのがしっくりこなかったです。 これはたぶんRqさんの感覚のほうが正しいのではないかと。

>　私が最初から言っているのは、「術語に過剰な期待をするのはいかがなものか」ということです。 >　集合論で見て、サイヤ人はスーパーサイヤ人のスーパーセットですが、やっぱりスーパーサイヤ人の方に「スーパー」が付いている。そういう言葉の使い方が現実にある以上、「スーパークラス」という言葉に違和感を感じる人もそりゃいるだろうねえ、と言っているだけです。 そうかなぁ、とも思ったのですが、一人で３連投するのもどうかと思ったのでやめときました。 「スーパークラス」という用語に違和感を感じるのは構いませんが、しかし「基底クラス」という言い方はもっとまずいと思うのです。前述したように、クラスは上下関係ではなく包含関係にあるからです。 「スーパーサイヤ人の方がスーパーだ」という考えに固執していると、「サブクラス（に属するオブジェクト）は機能が多いものだ」という誤解を招きます。 「スーパークラス」「サブクラス」という用語を使わなくても、自然に集合論的考え方ができるのであれば、それで結構だと思います。 ただ、違和感を感じるからといって否定するのでは、何かを学習することはできないでしょう。学習は違和感を覚え、それを解消することによって積み重ねていくものです。 前にも言いましたが、「スーパークラスはサブクラスよりも『含むものが多い』という点で集合の能力が上、すなわちスーパーだ」という考え方もできます。そして、「スーパーサイヤ人は機能が多い方がスーパーなのに、集合論は機能が少ないほうがスーパーなんだ。そういうものなんだ」と違和感を感じたまま暗記するよりは、是非、違和感を解消していただきたいと思うのです。 というわけで、俺は「スーパークラス」「サブクラス」という呼び方を布教していきたいと思います。 > で、集合論で考えるなら円は楕円のサブセットなのであって、それを「客観的な視点などというものは存在しません」などと言って否定してしまったら、それこそ数学を全部敵に回すと思うんですが、如何? 「円は楕円のサブセットである」というのは、集合論が決めることではありません。数学（幾何学）が決めることです。 （どんな論理に基づくかは知りませんが）「楕円は円のサブセットである」と言っても、それは幾何学的には間違えているかもしれませんが、集合論的には間違えていません。集合論は集合の関係を提供するのみで、その中身の妥当性にまでは関与しないからです。 そして、数学さえ真理ではありません。かつてはユークリッド幾何学が真理とされていた時代もありましたが、今では「ユークリッド幾何学は、いくつかの都合のいい前提の基にのみ成立する、一面の真実でしかない」ということは広く知られています。

>ただ、違和感を感じるからといって否定するのでは、何かを学習することはできないでしょう。学習は違和感を覚え、それを解消することによって積み重ねていくものです。 だーかーらー。 いつ誰が、スーパークラス、サブクラスという言葉を否定しましたか? 何度も繰り返しますが、私が言っているのは、 「術語に過剰な期待をするのはいかがなものか」 ということだけです。 スーパークラスという言葉を否定した覚えも、スーパークラスは集合論で言えば スーパーセットである、というのを否定した覚えもありません。

>何度も繰り返しますが、私が言っているのは、 >「術語に過剰な期待をするのはいかがなものか」 >ということだけです。 >スーパークラスという言葉を否定した覚えも、スーパークラスは集合論で言えば >スーパーセットである、というのを否定した覚えもありません。 よくわかんなくなってきました。「過剰な期待をするな」とはどういうことですか？ 「違和感を覚えるな」というのは無理な期待だ、ということでしょうか？

>よくわかんなくなってきました。「過剰な期待をするな」とはどういうことですか？ >「違和感を覚えるな」というのは無理な期待だ、ということでしょうか？ 「術語に対して」過剰な期待をしてもしょうがないのでは、ということです。 この議論の最初のほうで、CESさんは >例えば、「クラス」という用語の意味は「分類」であって、「原型」ではありませんから、 ということを書いています。 でも、「クラス」という言葉の辞書的定義が「分類」だったからといって、 術語として使われるときそのままの意味とは限らないし、「クラス」という 言葉を選んだ人が間違えたのかもしれない。だから、その言葉の意味に 過剰な期待をしてもしょうがないのでは、と言っているのです。 # クラスを分類とする考え方を否定しているわけではありません。 CESさんはこうも書いています。 >「クラスとは分類である」という考えをすると、具体的なものはオブジェクトで、 >クラスは全て抽象的なものということになるからです（その点、「抽象クラス」 >ってのは良くないネーミングだと思います）。 私の返答がこう(「スーパークラス」の話は発散するので省略)。 >それはそうかもしれませんけど、具体的なオブジェクトにできないものが >抽象クラスで、具体的なオブジェクトを作れるものがconcrete classってのは、 >それほど無理はないんじゃないでしょうか。 「それはそうかもしれませんけど」「それほど無理はない」んならいいじゃん、 術語に過剰な期待をしてもしょうがない、と私は言っているわけです。 クラスを分類として考えるのがよいとCESさんがお考えなら、それが具体的に 有効であるケースを、例示して主張するのがよいのではないでしょうか。 「そのへんの入門書にある考え方だと、こういう例ではこういうモデリングを してしまいがちだけど、分類として考えればこんなモデリングになって、 こういう拡張をするときのことを考えたらこっちのほうが修正箇所が はるかに少なくてすむよね」とか。 結城浩さんが書いておられるように、「例は嘘をつかない」ですから。 http://www.hyuki.com/dig/eg.html

>「術語に対して」過剰な期待をしてもしょうがないのでは、ということです。 >この議論の最初のほうで、CESさんは > >>例えば、「クラス」という用語の意味は「分類」であって、「原型」ではありませんから、 > >ということを書いています。 >でも、「クラス」という言葉の辞書的定義が「分類」だったからといって、 >術語として使われるときそのままの意味とは限らないし、「クラス」という >言葉を選んだ人が間違えたのかもしれない。だから、その言葉の意味に >過剰な期待をしてもしょうがないのでは、と言っているのです。 ># クラスを分類とする考え方を否定しているわけではありません。 では、極論すれば、辞書的な「分類」という意味と、術語としての「クラス」という用語は切り離して考えるべきだ、ということ？ もっと言ってしまえば、「クラス」ではなくて「りんご」でも別に良かった…ということ？ 「りんご」の辞書的な意味は明らかに違うけれど、術語なんだから、それで通じれば別にいいじゃん…と。 しかし、如何に述語だとは言っても、何の根拠もなく選ばれた言葉であるはずはなし、そして、「クラス」には「分類」という意味があって、オブジェクト指向のクラスを「分類」として捉えると自然なのは事実なんだから、その言葉はそのような意味を持って選ばれたと考えるのは、過剰ではないと思うのですけれど。 本当に「何の根拠もなく選ばれたはずはない」のかどうか、あるいは根拠があったにしても「『分類』という意味を意図して選んだ」のかどうか、その真相はわからないのですが、別に後付けの意味だとしても、それはそれで構わないと思います。意味がないよりはずっといい。 >「それはそうかもしれませんけど」「それほど無理はない」んならいいじゃん、 >術語に過剰な期待をしてもしょうがない、と私は言っているわけです。 「りんご」だったら「それほど無理は無くない」と思うけれど、まぁ極論だからそこに突っ込むのは無し。 >クラスを分類として考えるのがよいとCESさんがお考えなら、それが具体的に >有効であるケースを、例示して主張するのがよいのではないでしょうか。 例示が必要でしょうか？　「is-a」「汎化-特化」の考えは、まさに分類だと思うのですが（「汎化」「特化」という用語を誰が考えたかは知りませんが、いくらこれが術語だからと言って「低機能」「高機能」という意味でないのは明らかでしょう）。