K.Maebashi's BBS

いつも「プログラミング言語を作る」を楽しく拝見させて頂いています。 早速、「正規表現ライブラリ鬼車の搭載」を拝見させて頂きました。 最後の方に、正規表現関連の関数がグローバルということが 書かれていましたが、私は、Pythonは、よく知らないのですが、 何で正規表現の関数をクロージャに押し込んで提供していないのですか？ 例えば、Luaであれば、Stringというクロージャに入っています。 また、crowbarには、まだハッシュを組み込んでなかったと思うのですが、 ハッシュは組み込まないのですか？ 必須なデータ構造だと思います。 あと、最近、Luaを勉強していて、組み込み言語と謳っている割りに 例えば、LuaとCとのインタフェースを書くのがかなり面倒で 少しがっかりしているのですが、crowbarはぜひとも組み込み部分を強化 して欲しいです (例えば、C側で、LuaのTableをダイレクトに作れず、Luaのスタックを 経由しないとできないので面倒)。 鬼車を搭載しても、まともに張り合ったら、Rubyに対抗するのは 難しいと思いますので、組み込み用スクリプトでメジャーなものは なさそうなので、そういう方向はどうでしょうか？ 私は、D言語やioはあまり知らないですが、組み込み用言語の デファクトスタンダードとか、存在するのでしょうか？

私は、ＬＩＮＵＸで動くＣＡＤを作りたいと思っています。 その中で、マクロのようなものを組み込みたいと思って、 自分で少し考えていたんですが、これは、これで、また新たな 専門的な知識が必要だと感じましたし、ＣＡＤ自体まだまだな 自分には、いつになることかとたまに、どこかにないかなと探 し続けていました。 今回ここにたどり着いて、サンプルを動かしてみました。 すごいですね。 ホームページ上では、僕が作ったソースに組み込めるようなことが 描いてありました。まだ試していませんが、試せるところまで進んだら ぜひ、使わせてください。 僕は、プロでもないし、未熟者ですが、そのときは、いろいろ質問 させてください。 最近、あれもやりたい、これもやりたいと悩んで、ＣＡＤ自体手を付けられない 状態でした。 このサイトに来て、このようなすばらしいものがあるのなら、 今は、マクロについては何も考えず、目標のＣＡＤに専念しようと やる気が起きてきました。ありがとうございます。

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

旧掲示板として存続してきたOTD版の掲示板ですが、最近は広告書き込みばかりで、 その量も尋常ではないので、閉鎖しました。トップページにも案内を出しましたが、 過去ログは以下のURLから参照できます。 http://kmaebashi.com/bbs/otdindex.html どうでもいいことですが、過去ログは、30件ずつブラウザで表示し、 HTML保存(ここは手作業)したものに対し、crowbarで変換をかけることで 生成しました。crowbarで行ったのは、広告やJavaScriptの削除、前後の ページへのリンクの付加です。 バリバリにうちの掲示板のHTMLに依存したスクリプトなので、そのまま 他の人の役に立つ可能性はゼロですが、数少ないcrowbarのサンプルソースとして 以下に公開しておきます。 http://kmaebashi.com/bbs/conv_crb.html

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

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

>こんばんは。archerと申します。 >「プログラミング言語を作る」のページの下のほうにある、 >「現状の最新版のダウンロードはこちらから。」のリンクが切れている（Not Found）ようです。 ご報告いただきありがとうございます。修正しました。

こんばんは。archerと申します。 「プログラミング言語を作る」のページの下のほうにある、 「現状の最新版のダウンロードはこちらから。」のリンクが切れている（Not Found）ようです。 とりあえず、報告まで。

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

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

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

こんばんは。前回は、はじめてであるのに名乗らずに失礼しました。 自分が浅学なのを暴露してしまうような気がしますが…こういう理解でいいのかな、と 少し確認の意味で書いてみます。 ＣＥＳ さん： >どの程度のことを「大規模」と言うかわかりませんが、オブジェクト指向が適用できない（適用する必要が無い）ほど小規模なものとなると、せいぜい 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のサブクラスにするのが適切とも思えません)。 実装面べたべたで行くと、抽象度の高い設計ができずに後ではまるといった 問題があるのかもしれませんが、実装を離れて理論で突っ走っても、結局変なことに なってしまうように思います。月並みですがバランスが大事、ということでしょうか。