K.Maebashi's BBS

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

遅ればせながら、あけましておめでとうございます。 今年もよろしくお願いいたします。 つーわけでもう元日は終わっていますが壁紙変更。 去年もこれやって微塵も反応なかったんですがめげない。

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

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

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

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

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

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

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

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

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

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

＃話が脇にそれてたので源流復帰。 > ・大規模なプログラムの開発でないと効果を発揮しない どの程度のことを「大規模」と言うかわかりませんが、オブジェクト指向が適用できない（適用する必要が無い）ほど小規模なものとなると、せいぜい 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. （経験は素晴らしいものです。再びそれを作る場合、それによって誤りを認識することができます。） まぁ、最初のうちはわからないなりに模索して失敗してみろって事ですね。 そのうち、だんだんとありがたみがわかってくると思います。

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

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

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

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

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

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

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

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

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

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

はじめまして。 >いろいろなオブジェクト指向入門を見てきて、オブジェクト指向は > ・大規模なプログラムの開発でないと効果を発揮しない > ・プログラムを分割することが大切 > ・デザインパターン（設計）を知らないといけない（？ >という特徴を持っているのではないかと思っています。 デザインパターンは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)は どれも抽象クラスですし、使用範囲を間違えなければ、有効に使えると思います。

オブジェクト指向再入門、とても面白く読ませていただきました。その中で ・手続き型言語を習得している「途中」の自分がどのようにオブジェクト指向を実践していけるのだろうか というところで疑問を抱いたので質問したいと思います。ここでのオブジェクト指向議論とは違う疑問なのかもしれませんが、書きたいと思います。 自分は、対象読者とされている「手続き型言語を習得し」た人ではないです。大学に入ってからプログラミングを習っています。使っている言語は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)」 というもので、これにのっとって実践を進めれば今ある機能を追加していくということでオブジェクト指向の利点を理解しやすく、かつ小さなプログラムを大きくしていけるのではないかと考えています。ここでの継承は、コードの再利用ではなく堅実なプログラムを組むため、という理由付けになりオブジェクト指向と呼べるのでは？と思っています。 しかしそのためには手続きを分節化し、プログラムを設計する能力がいるだろう、と思っています。 このような場合に、デザインパターンが有効なのだと思いますが、具体的にどうプログラムを組むのか、というところで自分は躓いている状況です。 しかし、上記のようなオブジェクト指向「初」入門が、オブジェクト指向言語から入った人には必要なのではないか、と思いました。再入門という観点からは不適切かもしれませんが、提起してみました。 乱文失礼いたしました。

>三角格子の各線を(軸でなく)座標値とすれば、隣に行くにはふたつの値を >いじらなければいけませんから、これはNykRさんのものと同じになるのでしょうか。 えーっと、各線に座標値を割り当てて、 　　 ｜　　　　　｜ 　　 x0　　　　　x1 　　 ｜　　　　　｜ 　　／＼　　　　／＼ 　y0　 z0　　y1　　z1 ／　　　 ＼／　　　　＼ 「各マスの中心から、各辺に対して伸ばした線を軸とする」と、 x0＝x1, y0≠y1, z0≠z1 だから 隣に行くためにいじる値は2つになりますね。 私のと同じになるみたいです。 んーと、でも三角格子の各線を軸とする方法もあると思いますよ。 私の方法をもう少しまじめに書きます。 んーと、 上から下へのラインを x軸 右上から左下へのラインを y軸 左上から右下へのラインを z軸 とすると、あるマスから例えば左右のマスへ移動するとき、 x軸方向に0、y軸方向に±1、z軸方向に±1 (× 辺の長さ分) 動かさなきゃいけません。 他の2方向についても2つの値をいじらなきゃいけませんよ、と。 で、この場合は、辺と座標軸が1対1に対応しています。 (ぱ)さんの最初の方法は、本来同一平面上にあるマスを別の平面にある要素(配列の)として表そうとしたところに問題があったのではないかと。

>>各マスの中心から、各辺に対して伸ばした線を軸とする、というイメージです。 > >ええと、あるマスが位置(i, j, k)にあったとします。 >このとき周りのマスは ... >右下 と 右隣の左下 のマスは同一のはずなので、別の場所にあるのはまずいのではないかと。 あれっ? 確かにおっしゃる通りです。よく考えずに書いていました。 いやそのマスと座標値が1:1対応しなきゃいかんよね、とは考えていて、 三角格子の交点をつまんでひっぱり挙げるとついて来る線は3本に決まるから、 1:1対応だよな、とか思っていましたが、この時三角格子の各線は座標値を 表しているのであって、軸を表しているわけではないですからね。 とここまでは実は考えていたつもりなんですが、同じだよな、となぜか (2次元の座標系のイメージにひきずられていたのでしょう)考えて 先の投稿のように書いてしまったわけなんですが、 三角格子の各線を(軸でなく)座標値とすれば、隣に行くにはふたつの値を いじらなければいけませんから、これはNykRさんのものと同じになるのでしょうか。

横から失礼します。 >>>六角オセロの場合は、3次元の配列にすると、はさむところの判定が >>>楽にできるかもしれませんね。各添え字の上限が一定しないですけど。 >> この場合、最初の2次元は私の書いたx,y座標ですか? >> 3つめの座標はどういう方向になるんですか? > >各マスの中心から、各辺に対して伸ばした線を軸とする、というイメージです。 ええと、あるマスが位置(i, j, k)にあったとします。 このとき周りのマスは 右隣 : (i+1, j, k) 右下 : (i, j+1, k) 左下 : (i, j, k+1) 右隣の左下 : (i+1, j, k+1) にあるはずですよね？(とは限りませんけど、気にしないことにします) 右下 と 右隣の左下 のマスは同一のはずなので、別の場所にあるのはまずいのではないかと。 何か勘違いしてたらすいません。 ＃ こんなの思いつきました。直方体を斜めから見たら6角形になることを利用する訳ですが、 ＃ どっち向きでも添字を2つ動かさなければならない・・・。 ／ ＼ ／ ＼ ／ ＼ |＼ ／|＼ ／|＼ ／| ＼|／ ＼|／ ＼|／ ＼ 　 |＼ ／|＼ ／|＼ ／| ／ ＼|／ ＼|／ ＼|／ |＼ ／|＼ ／|＼ ／| ＼|／ ＼|／ ＼|／ ＼ 　 |＼ ／|＼ ／|＼ ／| 　 ＼|／ ＼|／ ＼|／

>>>六角オセロの場合は、3次元の配列にすると、はさむところの判定が >>>楽にできるかもしれませんね。各添え字の上限が一定しないですけど。 >> 3つめの座標はどういう方向になるんですか? >各マスの中心から、各辺に対して伸ばした線を軸とする、というイメージです。 >4角形だと、辺の数が4だから、軸の数は2, >6角形だと、辺の数が6だから、軸の数は3, >この方法だと、ある軸の数値を変化させることで、次々と隣のマスが現れますから、 >はさむところの判定が楽にできるのではないかと。 なるほどぉ。勉強になります。 ありがとうございます。 ...とは言っても実際にゲームを作ったりはしないのですが 何しろ時間がなくて...能力も?(^^;) >>友人や家族でこのゲームを良くやるのですけど、 >>いつもどうやってプログラムするのかなって考えていたりします＜－職業病?(^^;) >>そういう融通が効く人間ってすごいなぁとか思います。 >人間の「知能」って不思議です。 最近、コンピュータなしだとほとんど仕事ができないので 考えるのは全てコンピュータの方で私自身はコンピュータの (特殊な)入力補助装置になりさがっているのではないかなどと 感じ出しているのですが、そう錯覚することが「知能」なのでしょうか。

>>六角オセロの場合は、3次元の配列にすると、はさむところの判定が >>楽にできるかもしれませんね。各添え字の上限が一定しないですけど。 > この場合、最初の2次元は私の書いたx,y座標ですか? > 3つめの座標はどういう方向になるんですか? 各マスの中心から、各辺に対して伸ばした線を軸とする、というイメージです。 ＼ ＼ ＼ ／＼／＼／＼ ―｜00｜01｜02｜ ＼／＼／＼／＼ ― ｜10｜11｜12｜ ／＼／＼／＼／ ―｜20｜21｜22｜ ＼／＼／＼／＼ ― ｜30｜31｜32｜ ＼／＼／＼／ ／　 ／　 ／ 4角形だと、辺の数が4だから、軸の数は2, 6角形だと、辺の数が6だから、軸の数は3, この方法だと、ある軸の数値を変化させることで、次々と隣のマスが現れますから、 はさむところの判定が楽にできるのではないかと。 >友人や家族でこのゲームを良くやるのですけど、 >いつもどうやってプログラムするのかなって考えていたりします＜－職業病?(^^;) >そういう融通が効く人間ってすごいなぁとか思います。 昔は「コンピュータがチェスで人間に勝てたら、そのコンピュータには知能が あるとみなしてよいのではないか」という議論があったそうですが、 今じゃ誰もそんなこと言いませんもんねえ。 人間の「知能」って不思議です。