オブジェクト指向。教科書と現実のはざまで
新人教育のため、久しぶりにオブジェクト指向の教科書をつらつら眺めていると、ふと何点かの疑問がわいてきました。
■「集約」の章にて
「集約」の説明用に、『ハンドル』『タイヤ』『エンジン』などが集約されて『自動車』になっている図が掲載されていました。
○（ささやかな）疑問その1
そういえば昔、日本やヨーロッパの自動車メーカーから部品を調達して組み立てた中国製の自動車が、別の国では安全性の問題から自動車として認められなかった、というニュースがあったような……（うろ覚え）。
各部品はちゃんとしていたから、自動車は走ることができたのでしょう。でも、各部品が「集約」されても『自動車』として認められない場合がある。そういうのって、どう表現するのだろう？
○（ささやかな）疑問その2
唐突ですが、『歌』を「集約」で表現したら、どうなるのだろう？ 『歌詞』と『曲』、『歌手』の「集約」？？？
そういえば昔（昔のことが気になるのは、年をとった証拠かも）、西田敏行が司会をしていたバラエティで、歌詞や歌手の泣けるエピソードを紹介した後、その歌が流れて、スタジオが感動する、という番組がありました。
歌詞や歌手の『エピソード』は、『歌』に「集約」されるのだろうか？
○（ささやかな）疑問その3
その2に関連して。
人類が滅亡した地球上に、ラジカセが１台。まだ電池が残っているのでしょう。そこからは氷川きよしの『ズンドコ節』が流れている。これは『歌』と言えるのでしょうか？
■「継承」の章にて
「継承」の説明用として、『動物』から『人』が「継承」され、『人』から『社員』が「継承」されている図が掲載されていました。演習として、『イス』『猫』『人』『鳥』などの絵があり、これらの関係性を図示せよ、とありました。
○（ささやかな）疑問その4
実際のシステム開発現場で、『社員』というクラスを設計することはありますが、それを『人』クラスからの「継承」とすることはほとんどありません。というより、『人』というクラスを設計した場合、多くの場合は「バカ！」としかられそうです。でも、教科書の例題にはそう書いてあります。「教科書に書いてました」と言われた際、何と返事すればよいのでしょう？
○（ささやかな）疑問その5
演習の解答例は、『イス』は『家具』から「継承」され、『鳥』は『鳥類』から、『人』と『猫』は『哺乳類』からの「継承」。『鳥類』と『哺乳類』は『生物』に抽象化された後、『家具』と合わせて『オブジェクト（モノ）』に抽象化されてました（一例との注釈はあるものの）。
では、『イス』と『猫』は『4本足』からの「継承」。『鳥』と『人』は『2本足』からの「継承」という回答が出た場合、これは間違いなのでしょうか？
使っている教科書の質や、対象者のレベルもあるのでしょう。でもWeb上にある数々の関連サイトを眺めても、なんとなく分かったような気になる、「概要」だけを説明しているだけのもの。
もしくは、概念はそこそこに後は具体的なコーディングに流れ込んでゆくページを多く見かけます。
新人相手にグチグチ言うと混乱させるだけなので、疑問はコラムに投稿してストレス発散するとして、（ささやかな）疑問を1つでも質問してくれるような骨太新人が1人でもいてくれることを願う今日このごろです。いたらいたらで、面倒くさいのかもしれませんが……。
最新の投稿
コメント
私も数年前にオブジェクト指向について勉強した際に、これのせいで詰まりました。
抽象的すぎてさっぱり意味が分からないんですよね。
詳細は覚えてませんが、ポリモーフィズムなど奇々怪々な例えでウンザリしました。
もっと実際のプログラム作成を想定して例示してくたほうがよっぽど理解しやすいと思うんですけどね。
山無駄
はじめまして粕谷大輔 様
私はどちらかとおいうとプログラムではなく、設計側の人間です。
だから設計を想定した教科書があるとうれしいです。
単純に「オブジェクト指向」というだけではなく、開発者向け、とか設計者向け
とか整理されると良いのでしょうね。
山無駄
はじめまして Aron様
仰れれる通りで、オブジェクト指向の考え方の説明と、オブジェクト指向を
使った設計やモデリングの説明は違うのだ、という事に気がつくのに、自身
時間がかかった様に思います
山無駄さんこんにちは
さっそくオブジェクト指向ネタ盛り上がってますね。「設計側」ということですが、プログラムを書くというよりはＳＥみたいな仕事をしているのでしょうか？
継承に関しては、クラスライブラリのようにクラスをたくさん書けば、共通部分は既定クラスにまとめたほうがいい、という使い方が自然な使い方であるので、あまり社内ＳＥの内製開発などはクラスライブラリを使う立場であるので、必要ないと考えてます。
ポリフォーニズムに関しても、あえて、そのもののクラスでインスタンス生成せず、既定クラスでインスタンス生成を行っている例はＷＥＢ上でみても非常に少ない、＠ＩＴの会議室でも、そんな例は見たことないです。
ＧｏＦのようなポリフォーニズムに執着した例は実践では本当にあるのでしょうか？ＧｏＦは非常に凝った例ですが、結局やっていることは種類の違う派生クラス間の対応付のように見えます。頭の体操にはなりますが・・・
みながわけんじ
またまたすいません。
「ポリモーフィズム」の間違えです（笑）。
山無駄
はじめまして。みながわけんじ様。
オブジェクト指向ネタが、こんなに盛り上がるとは思いもよりませんでした。
正直驚いております。
わたしの仕事は、私自身はSEだと思っておりますが、世間一般化からすると
少し違うかもしれません。お客様の業務を理解し、こんなシステムですねと
全体イメージを提案し、受注できたらメインとなる機能のラフスケッチを書
きます。後は開発担当に任せて開発してもらい、途中すり合わせ、お客さま
に展開する感じです。
一見オブジェクト指向とは関係ない様に思えます。確かに表記法であるUML
などを使うことはほとんどありません。ビジネスデザインをUMLで記述する、
という考え方もあるようですが、お客様に理解してもらうに壁があるのです。
しかしオブジェクト指向の考え方は、とても大切（多くの示唆に富んでいる
）だと思っています。
物事を整理するのにとても役立ちます。
少し違った立場でポリモーフィズムやデザインパターンの話をさせてもらい
ますと（GoFではありませんがビジネスデザインもデザインパターンがある
と思います）、意味も分からずガチガチに使ってゆくのではなく、その考え
方をしっかり理解することが大切で、理解したうえで自分が開発しているシ
ステムに対してどう適用するか（踏襲するか、カスタマイズするか、適用し
ないか）を考えることが良い設計につながるのではないかと考えております。
だからこそ、若い人たちには教えられたことや教科書に載っている事を鵜呑
みにするのではなく、自分なりの考え方を持ってもらいたいと願っております。
ハムレット
面白いですね。
○（ささやかな）回答その１
同じ構成要素を持つ、別のクラスを定義する（例えばガラクタ）
確か鋼の錬金術師に、人間と同じ構成要素を持つけど、人間になり損ねたみたいなものが出てきましたよね。
○（ささやかな）回答その２
普通なら、エピソードは「付随」するものだから、「常識」的には「集約」とは違うかもしれない。しかし歌詞に「エピソード」が集約されるようなモデルを構築する事は可能。
○（ささやかな）回答その３
「歌」が存在する前提条件として、「聞き手」を必須とするかしないかによって異なる。
○（ささやかな）回答その４
（私なら笑って）その「教科書」 には「なぜ」そう書いてあったの？
教科書の著者は何を考えてそう書いたのかな。？
○（ささやかな）回答その５
継承の意味を「生物学的」に捉えるなら×かな、
形態と機能から捉えるなら○かな。
要はConcern（関心事）によるでしょうね。
思うのですが、オブジェクト指向への理解を深めたいなら、技術者の方が書かれたオブジェクト指向設計やプログラミングの本を読むより、まず最初はトランスビューから出版されている池田晶子の「14歳からの哲学」を読んだ方がずっと為になります。オブジェクト指向について、何ら得るものは無いのですが、正しく読解できればオブジェクト指向を理解する為の幾つかの道具を得る事が出来ると思います。
○（ささやかな）質問１
電子回路の基本となる理論が、電磁波等の物理学ですが、同じようにオブジェクト指向の基本となる理論って何だと思いますか。
○（ささやかな）質問２
オブジェクト指向（プログラミング）には大別すると2種類あります。ひとつはクラスベースのオブジェクト指向、もうひとつは？
ではでは
ハムレット
追記です。
○（ささやかな）回答その４（別解）
私なら笑顔で、ゆっくりとした口調で１）～４）の順番で次の４つの問いをその生徒の方へ投げかけてみます。
１）あなたは○○（会社名）の方ですか？
２）あなたは○○（その方の氏名）さんですか？
３）あなたは日本人（相手の国籍に合わせて変える）ですか？
４）あなたは人間ですか？
その上で、各問いを受けた時の感じたことを聞いてみます。
もし「なぜそんな問いをするのですか」と逆に尋ねられたら「指導方法の教科書にそう書いてあった。」と笑顔で返してみましょうか。
ではでは。
nira
> オブジェクト指向の考え方の説明と、オブジェクト指向を
> 使った設計やモデリングの説明は違うのだ
想定している対象読者がプログラミング経験がないことを前提としている場合は、
モデリング手法の概念の説明に実世界の例を出すことは妥当だと思います。
当然、対象が違えばまったく別の例を出す（べき）でしょう。
「ささやかな疑問」については、それとは別の話で
何をモデリングしたいのか、そのモデルで何を表現したいのかという問題でしょう。
まともな教え方をしていれば、逆にそのような質問は出てこないと思います。
AC/DC
おお、2010年度、最大のコメント数を獲得した釣り名人みながわけんじ先生のご光臨だ！
この人のオブジェクト指向に関するうんちくは一見の価値ありだよ。
みながわけんじ先生語録
・「自分でクラスを作ってオブジェクト指向っぽいことをしている」なんてことはまったくない。
・staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。
・今回のコラムについては、オブジェクト指向がわかっていないから書いた。
・業務アプリケーションの実践においてはstaticと宣言されていれば、これはロジック関数であるということが人目でわかり、プロラムの可読性がかなりよくなるのです。
・いんやぁ、ここ１０年くらいは クライアント、WEBさーばー、データベースさーばーの３階層システムばっかり構築してますよ。
・ポリフォーフィズムという言葉が流行はじめたのは、Perfumeがポリリズムという曲をリリースしたころですか？？？
・ポリフォーニズムを使ってクラス構築するなんて、四暗刻で上がるくらいに一生に一度あるかないかのチャンスです。
・だから、オブジェクト指向プログラミングは実践では使えない。データベースを活用したほうが何万件の処理を高速に実行できるという意味でスケーラビリティが全然違うのです。
・ふざけているわけではなくオブジェクト指向言語はデバックという面で優位性があるかという問題です。
・非常に失礼なのですが、あなたは九州大学農学部卒という経歴で、何か私に対しひがみを感じているのではないのすか？ 私は学部は東北大学で大学院が東工大です。
・この歳になったら学歴なんて関係ないです。むしろ工学部出身者が中心のこの世界でTDaさんは、よく勉強して極めているなあ・・・なんて関心します。努力されたのでしょうね。
・今の時代、学歴にあぐらをかいているような人は生き残れません。
・インスタンスはどらえもんの「どこでもドア」です！！！
・私はIS部門の人間なんです。SIerの客なんですよ。私に嫌われたらどうなりますか？皆さん生きていけないですよ！
・インスタンスを生成する必要があるものが静的であるとすると、インスタンスを生成するものは動的ということではないか？
・もともとのコラムで扱いたかったことはIS部門向けにVisual Studioを使ったRAD開発です。
・やっぱりデザインパターンがキーワードでしたか。本コラムを書くまで知らなかった言葉なので確かに皆さんに言われるように私は勉強不足ですね。
・インスタンス ・・・ 実体 static ・・・ 静的
くわしくは、
http://el.jibun.atmarkit.co.jp/minagawa/2010/04/post-ebc4.html
AC/DC
あれだけ、オブジェクト指向について無知をさらけだしておいて、ぬけぬけとGoFがどうの、ポリモーフィズムがどうのと、口にできるものだとある意味感心するよ。
しかも、「ポリフォーニズム」って。
４ヶ月前と同じいい間違いをして進歩がない。
あいかわらずstatic使いまくり？
自分でクラス定義したこともないの？
山無駄
はじめまして。ハムレット様
>確か鋼の錬金術師に、人間と同じ構成要素を持つけど、人間になり損ねたみたい
>なものが出てきましたよね。
錬金術の基本は「等価交換」で、人間の構成要素をだけで人体錬成を行うと術者に
リバウンドがおこる、というやつですね。自動車にしろ、構成する部品に加えて組
立て加工の際に使われるエネルギーや技術やノウハウなど、目に見えない色々なも
のが結晶しているのしょうね（血と汗と涙も含め）。
>まず最初はトランスビューから出版されている池田晶子の「14歳からの哲学」を
>読んだ方がずっと為になります。オブジェクト指向について、何ら得るものは無い
>のですが、正しく読解できればオブジェクト指向を理解する為の幾つかの道具を得
>る事が出来ると思います。
「14歳からの哲学」は読んだことがありませんが、哲学書などがオブジェクト指向
の参考書となる事には同意。ただ個人的には、哲学者思想がオブジェクト指向理解
の為の道具になる、というよりオブジェクト指向の理解が自身の哲学や思想を持つ
ための一助になる、という考え方の方が好みです。
○（ささやかな）質問１ に対する（いい加減な）回答
認識学（そんな学問あるかは別として）と情報理論。シミュレータを作りたかっ
た人とたちが、いかに現実世界のものを忠実にコンピュータ上に表現するか、
という事を考えていった結果、人がどの様に世界を認識するか、という所に行き
ついた結果だから。私はオブジェクト指向の成り立ちをそう理解しております。
○（ささやかな）質問２ に対する（いい加減な）回答
プロトタイプベース。人工物に対する、生物の対比？
山無駄
はじめまして nira様
>モデリング手法の概念の説明に実世界の例を出すことは妥当だと思います。
>何をモデリングしたいのか、そのモデルで何を表現したいのかという問題でしょ
う。
そうそう。説明する新人は、当然プログラミングに対する知識も高くないです。
だから実世界を例にするしかないのですが、そうなると何をモデリングしようとし
ているのか、という前提条件が必要になってきます。そうなると「モデリングとは何らかの目的を持って現実世界を一つの視点で云々」というモデリングの話になり
余計に新人を混乱させてしまう様な。。。
分からなくてもよいから最初から厳密に教えるか、今は分かった様な気になっても
らっておいて後からきっちりと教えるか、ですね。
山無駄
はじめまして AC/DC様
コメントありがとうございます。しかしながら内容が、みながわけんじさんに対
するもので、本投稿に対するものではない様ですので、ご返事は差し控えさせて
もらいます。
また、もし みながわけんじさんよりコメントの削除依頼がありましたら、対応
させていただきます。ご理解のほど、よろしくお願いいたします。
flatline
はじめまして。
AC/DCさんに味方するわけでは決してないのですが、くだんのコラムを一読されれば、みながわけんじさんがオブジェクト指向に関して、ろくな知識もないまま「使えない」と発言しているのは確かです。
今回でも、
>ポリフォーニズムに関しても、あえて、そのもののクラスでインスタンス生成
>せず、既定クラスでインスタンス生成を行っている例はＷＥＢ上でみても非常に
>少ない、＠ＩＴの会議室でも、そんな例は見たことないです。
と発言されています。「既定」というのは「基底」の間違いだと思いますが。
これ、果たしてそうでしょうか？
たとえば、Javaで、
List userNameList = new ArrayList();
と宣言するのは、ある程度の経験があれば、ごく普通のことだと思います。
何を調べて「ＷＥＢ上でみても非常に少ない」と言っているのか疑問です。
本コラムの内容について言うと、オブジェクト指向の教え方については、確かに
難しいですね。私もたまに新人に教えることがありますが、あまり抽象的なことを言っても「だから何？」という顔をされるので、コーディングに進むことが多いです。
ただ、オブジェクト指向は、わからないままでもコーディングしていくと、ある日突然理解できたりするので、それでもいいのかなと思っていますが。
ArrayList list = new ArrayList();
のように基底クラスを使わない例が一般的です。
そのように解説しているＷＥＢサイトも実際にあります。
http://www.melma.com/backnumber_120830_3087823/
flatline
こんにちは。
>ArrayList list = new ArrayList();
>のように基底クラスを使わない例が一般的です。
たまたまそのように解説しているサイトがあったからといって、「一般的」とはいえないのでは？
オブジェクト指向を少しでも勉強されたことがあれば、「クラスではなく、インターフェースに向かってプログラミングしろ」という言葉を読んだはずです。
その言葉が間違っていると思うのであれば、その理由を述べるのはいいでしょう。その意見が理にかなっているのであれば、議論にもなるでしょうし、有意義だとも思います。
しかし、「基底クラスを使わない例が一般的です。」と断言するのは、みながわさんの多いとはいえない（オブジェクト指向に関して）経験の範疇でしかないでしょう。
失礼ですが、前のコラムを読む限り、何が「一般的」なのかを判断できるほど、みながわさんがオブジェクト指向に通じていらっしゃるとは思えません。
みながわけんじ
>オブジェクト指向を少しでも勉強されたことがあれば、
>「クラスではなく、インターフェースに向かってプログラミングしろ」
>という言葉を読んだはずです。
こうのように、flatlineさんが書いたことことは、すべてのオブジェクト指向入門書に、
「クラスではなく、インターフェースに向かってプログラミングしろ」
と書いてあるとflatlineさんは断言しているわけですね。
「クラスではなく、インターフェースに向かってプログラミングしろ」
の意味がわからない人はオブジェクト指向の片鱗もわかっていないとflatlineさんは断言するわけですね。
こういう個人的な思い込みは、このコラムのテーマである新人にオブジェクト指向を教えるというさまたげになると思います。
私は、「クラスではなく、インターフェースに向かってプログラミングしろ」の意味は、何かインターフェイスを実装することによりメリットがあるためで、そのメリットを享受するためには、インターフェイスを使ってインスタンス生成したほうがいい、という意味にとります。List を使うメリットをflatlineさんは説明すべきです。
エンジニアコラムはＳＥ，ＰＬ, インフラ、いろいろな立場の人が見ているわけで、わかりやすく親切にコラムを書いていただきたいものです。
山無駄
はじめまして flatlin様
>AC/DCさんに味方するわけでは決してないのですが、くだんのコラムを一読されれ
>ば、みながわけんじさんがオブジェクト指向に関して、ろくな知識もないまま「使
>えない」と発言しているのは確かです。
みながわけんじさんのコラムは拝見しました。すごいことになってますね。
ただ本コラムにて、みながわけんじさんのオブジェクト指向に対する知識や考え
方を取り上げているのではないという事はご理解ください。
>ただ、オブジェクト指向は、わからないままでもコーディングしていくと、ある日
>突然理解できたりするので、それでもいいのかなと思っていますが。
仰る通りで、机上だけではなく実践を踏まえて理解できることは多々あります。
そして、どこかでもう一度理屈に戻る機会があればよいのでしょう。
ただ、これがなかなか難しい…。
山無駄
みながわけんじ様 及び 皆さま
どうも期せずして議論を再燃させてしまったようですね。
オブジェクト指向を考える上で、こういった議論も大切なのかもしれませんが
（少し感情的になっているようですが）、残念ながら私自身プログラム側の人間
ではありませんので議論に参加できません。
つきましては、個別の議論はご遠慮していただきたく存じます。
もしこのまま盛り上がるようでしたら、誠に残念ながらコメントを削除させてい
ただきますこと、ご理解のほどよろしくお願いいたします。
flatline
すみません。確かに、ここでみながわさんのオブジェクト指向に関する無知を批判するのは筋違いでした。謝罪します。
ただ、オブジェクト指向について知識も経験もない人が、さも業界の共通認識であるかのように「基底クラス（抽象クラス）を使うのは一般的ではない！そんな例は見たことがない！」と断言しているので、「そんなことはない」と言いたかっただけです。
むしろ、積極的に抽象クラスやインターフェースを使用することで、オブジェクト指向の三大要素の１つである「ポリモーフィズム」の恩恵を享受することができるわけです。
もし何の知識もない新人エンジニアさんが、みながわさんの発言だけを読んで「抽象クラスやインターフェースは使い道がないんだ」と思い込んでしまうのが怖かったのです。
私が新人に教えるとき、抽象的な概念はほどほどにして、コーディングに進むと前に書きましたが、そのとき「今はわからなくてもいいから、インターフェースで宣言してね。おまじないだと思って」と言っておきます。まずは動くコードを、手を動かして完成させないと効果が実感できないからです。
その後で、コードをおいかけながら、ポリモーフィズムについて説明します。新人さんも自分の書いたコードなら、理解しやすいので。
あくまでも私の経験ですが、概念をえんえんと時間をかけて説明しても眠くなるだけで理解度は低いです。とにかくコードを書かせて、具象クラスの生成にfactory を使うように拡張させていくと、ポリモーフィズムの利点について理解してくれることが多いです。
あと、みながわさんへ。
私は、あなたとは違って何も断言などしていませんよ。
山無駄
flatline様
>すみません。確かに、ここでみながわさんのオブジェクト指向に関する無知を批判
>するのは筋違いでした。謝罪します。
趣旨をご理解いただき、感謝申し上げます。
>あくまでも私の経験ですが、概念をえんえんと時間をかけて説明しても眠くなるだ
>けで理解度は低いです。とにかくコードを書かせて、具象クラスの生成に
>factory を使うように拡張させていくと、ポリモーフィズムの利点について理解
>してくれることが多いです。
おそらく、そのやり方が正解なのでしょう。我々の仕事がら、新人の進む道は開発
にどっぷりつかるか、コーディングはそこそこに設計やマネージメント、営業の道
を進むかに分かれてゆきます（正確には中小なのでマルチプレーヤになるので
すが）。しかし新人には座学の後、暫くは開発現場に放り込み、プログラムをガシ
ガシさせるつもりです。なので改めてポリもフィズムの利点を理解する機会はある
でしょう。
ただ、私自身の経験からするとコーディングは殆ど経験がなく、特にオブジェクト
指向言語での開発は全くありません。が、。システムを企画するにしろ設計するに
しろオブジェクト指向は大切な考え方だと思っておりますし（盲従するという意味
ではなく）、ポリモーフィズムなどの利点、欠点なども理解しているつもりです。
しかし残念ながら、インターフェースを使って実装した場合と、使わない場合が
具体的にどういう差になるかは、感覚的にまったくわかりません。
という所で、コーディングから離れた全く違う観点でオブジェクト指向というもの
を考えてみた際にどうなるのか、という問題提起が今回のコラムを書いた動機の一
つでもあります。
少し離れた視点での考え方が、今やっている事の理解への深まりに繋がりません
か？
AC/DC
山無駄さま、すみませぬ。
一晩置いておいたら、おいらの言いたかったことはflatlineさんがすっかり言ってくださったので、これで最後にします。
>こういう個人的な思い込みは、このコラムのテーマである新人にオブジェクト指向を教えるというさまたげになると思います。
まあどの口でこういうことを言っているのか呆れるやら気の毒に思うやらなんだけどね。
一番さまたげになっているのは、
>基底クラスを使わない例が一般的です。
なんて根拠のない断言をするご本人なんだよね。
>エンジニアコラムはＳＥ，ＰＬ, インフラ、いろいろな立場の人が見ているわけで、わかりやすく親切にコラムを書いていただきたいものです。
まさにそのとおりだよね。
で、ご自分は「わかりやすく親切に」書いてるって自覚があるのかな？
まあいいや。ここはみながわさんのコラムじゃないからね。
山無駄さま失礼しました。
もうオブジェクト指向に関してはみながわさんを無視するのがみんなが幸せになれる、たったひとつの冴えたやり方なんだろうね。
退散するよ。
ハムレット
こんばんわ。
お付き合い頂きありがとうございます。
>○（ささやかな）質問２ に対する（いい加減な）回答
> プロトタイプベース。人工物に対する、生物の対比？
そのとおりです。一世代前のJavaScriptのように、クラスではなく、変更可能な属性を持ったインスタンスのみでオブジェクトの定義を行うものでしょうか。
>○（ささやかな）質問１ に対する（いい加減な）回答
> 認識学（そんな学問あるかは別として）と情報理論。シミュレータを作りかっ
> た人とたちが、いかに現実世界のものを忠実にコンピュータ上に表現するか、
> という事を考えていった結果、人がどの様に世界を認識するか、という所にき
> ついた結果だから。私はオブジェクト指向の成り立ちをそう理解しております。
クラスベースのオブジェクト指向言語 Smalltalkの親にあたるSIMULA67って言語があります。ノルウェーの大学でシミュレーション記述用言語として開発されたものですが、クラスやインスタンス、継承、ポリモーフィズム（多態）といった概念もこの段階で確立されています。
で、彼らがそうしたクラスベースのオブジェクト指向で使われている概念をどこから借りてきたかというと、キリスト教神学における存在論からだそうです。中世から近代にかけて、神の創造した世界が如何に秩序だった世界か証明するために、多くの神学者がこの世界をどのように表現するか、つまり世界自体のモデルの構築にその叡智を傾け、血道を上げて取り組んできたのですが、そうした哲学的な営為の成果物が、実は意外なところで実用に提供されているというのは、何か意外ですよね。神学における存在論なんて、およそ実用から最も遠いところにある学問であるかのように見えるのですが。
ではでは。
山無駄
どうもAC/DC様。おはようございます。
flatline様も含め、コメントを読んだ知識と経験のない方々に勘違いさせては
いけない、という熱い思いは本当によくわかりました。
ただ、個別対応するよりは、もっと何故それが有益で大切なのか、という議論
をし、多くの人たちが建設的な議論に参加する方が、ネットの性質上、知識を
求めている方々の目に留まりやすくなるのではないかと思っております。
こりずに、これからも色々と議論させてください。
山無駄
ハムレット様。おはようございます。
キリスト教において神の存在を認識することは、世界を認識することだったと聞い
ております。西洋においては神の存在を確かめたくて哲学が生まれ、神を信じるために宗教が生まれ、その哲学と宗教をベースに科学が発達したそうな。
逆に日本は神の存在を疑う事もまなく受け入れてしまった。だから哲学が発達せ
ず科学も借り物になったとか、ならないとか。。。
個人的には、道具・方法論としてのオブジェクト指向も大切ですが、もう少し思想
としてのオブジェクト指向を議論しても良いかな、と感じております。お客様の混
沌とした業務を整理する際、もしくはシステムを０から企画する際に、とても重要
な考え方となります。
因みにご存じかもしれませんが、私のネタ帳の一つです。アリストテレスやソクラ
テスが出てきたあたりから頭痛くなりましたが。
http://www.atmarkit.co.jp/farc/rensai/column/world01/world01.html
flatline
おはようございます。
> という所で、コーディングから離れた全く違う観点でオブジェクト指向というもの
> を考えてみた際にどうなるのか、という問題提起が今回のコラムを書いた動機の
> 一つでもあります。
なるほど、コーディングから離れてオブジェクト指向ですか。
それはなかなか難題かもしれないですね。
動物→人→社員、みたいな概念を説明しても利点が理解しにくいと思います。というか、概念だけだと「それ何？おいしいの？」ってなりますな。
Hiro
コーディングから離れても、最終アウトプットが日本語かC++なのかの違いぐらいしかないと思う。（いや、日本語にするのもコーディングか？）
○（ささやかな）疑問その1、の（俺的）回答
とある国で自動車として認められない＝とある国で公道を走れない
つまり、車検のしくみをオブジェクト指向で表現したいと、
公道を走るには車検通って車検証やナンバープレートを手に入れる（集約する）必要がある。
車検を通すメソッドが自動車オブジェクトに付くのか、役場に実装されるのかは何を表現したいのかとか、人それぞれのセンスとかと思うが、車検通そうと（メソッド呼び出）した車が（その国の）必要条件揃ってなければエラー処理され車検証は交付されない。
これを細かく自然言語でコーディングすると車検関連の法律になり、人工言語でコーディングすると車検管理システムができあがる・・・のか？
○（ささやかな）疑問その2の番外への（俺的）回答
エピソードなんか知らなくとも、歌手が誰か楽器が何かさえも知らなくても、大半の人は歌を楽しんでいる。
だが、エピソードをしればより楽しめる。ジャケット等など含めて趣味、楽しみとしての歌がある。
逆に、レコード店での商売（だけ）を考えれば、媒体、管理番号、値段、etc・・・があればいい。おなじ歌でも趣味とはまったく別の世界。
なにを表現したいのかにつきるかと。
山無駄さん、こんにちは
ブラックジャックの話でピノコが交通事故で怪我をした犬を連れてきて、
「先生、治して」
ブラックジャック 「私は獣医ではないんだけど・・・」
といいながらも、ブラックジャックは犬を治療してしまいます。
人間と同じ生物という観点から、哺乳類は、食べる、寝る、糞をする、交尾するなど姿形がかわるけど共通の行為をする。我々を含めて生物が神の創造物だとすれば神は偉大なポリモーフィズムを使っていることになりますね！！
山無駄さんやハムレットさんが何百年、千年も変わらない真理を求めているのだとしたら、デザパタのサンプルコードを動かしてみて、オブジェクト指向をわからせたつもりになってるなんて次元が違いすぎますね。
山無駄
どうも flatline様
>動物→人→社員、みたいな概念を説明しても利点が理解しにくいと思います。とい
>うか、概念だけだと「それ何？おいしいの？」ってなりますな。
確かに、今の教科書の例示では何が利点なのかは分からないでしょうね。
ただその例示のあり方には疑問をていしているわけでして。
もしきちんとした説明ができるのであれば、意味も利点も分かってもらえるので
はないかと。。。難しいかなあ
山無駄
はじめまして Hiro様
>コーディングから離れても、最終アウトプットが日本語かC++なのかの違いぐらい
>しかないと思う。（いや、日本語にするのもコーディングか？）
うーん、もう少し抽象度の高い世界かな。オブジェクト指向云々よりもしかしたら
システム設計論の話に近いかもしれませんね。現実世界をコンピュータの世界に
落とし込んでいく際の、も少し現実世界に近いところでの議論。
>なにを表現したいのかにつきるかと。
そこです。コメントやTwitterでつぶやいていただいた多くの方が指摘してくれ
てますが、将に「何を表現したいのか」という事を無視して例示するから、分か
らなくなっている様な。これが教科書の一番の問題だと感じております。
山無駄
どうも みながわけんじ様
>人間と同じ生物という観点から、哺乳類は、食べる、寝る、糞をする、交尾するな
>ど姿形がかわるけど共通の行為をする。我々を含めて生物が神の創造物だとすれば
>神は偉大なポリモーフィズムを使っていることになりますね！！
ポリモーフィズムに限らずオブジェクト指向のキーワードである、クラスや継承
なども人が物事を認識するために重要な概念だと考えております。
だからオブジェクト指向をしっかり理解することは、大切なことかな、と。
>山無駄さんやハムレットさんが何百年、千年も変わらない真理を求めているのだ
>と?したら、デザパタのサンプルコードを動かしてみて、オブジェクト指向をわか
>らせたつもりになってるなんて次元が違いすぎますね。
そんな大袈裟なことではありませんよ。何百年どころか、何十年前かに技術者が
考え出したオブジェクト指向という叡智に敬意を表し、技術者として彼らの考え
を少しでも正しく理解をしたい思っているだけです。
デザインパターンにしても同様です。これもソフトウェア開発の先人達が、未来を
含めた多くの技術者の為に残してくれた叡智です。そこに貴賎の差はありません。
なので先人たちの叡智を少しでも正しく理解し、そして自分たちの知恵も加え、
また次の世代に伝えるのは、今の技術者達の責務だと思いませんか？
その共通認識に立った上での白熱した議論はとても重要だと思いますが、自分の
正しさを通そうとするだけの議論は、あまり好きではありません。
すこし、説教くさいコメントになりましたね（反省）。
AC/DC
少しまじめモードで。
少なくとも現在の一般的なソフトウェア開発において、オブジェクト指向を抜きにした開発というのはありえない。将来、オブジェクト指向を置換するような、○○指向開発手法のようなものが出現することは十分に考えられる。しかしそれまでは特殊な開発を除いてはオブジェクト指向技術がベストプラクティスであることは、まっとうな技術者ならば否定しないはず。
もちろん向き／不向きというものはあるので「オブジェクト指向がしっくりこない」という人がいるのはごく自然なことだ。
ではなぜ、みながわ氏の例のコラムが今にいたるまで批判され続けているのか。それは、氏がオブジェクト指向についての知識も経験もないにも関わらず、「オブジェクト指向は使えない！」とぶちあげたために他ならない。なおかつ「長い経験に基づく極意を教えてやる」という上から目線に基づく態度も反感を呼んだ要因だろう。
自分はデザインパターンに触れたとき、実用的かどうかは別として、その合理的な設計思想の美しさに感動したものだ。オブジェクト指向を使いこなしているエンジニア諸兄にも程度の差こそあれ、同じような思いを抱いた瞬間があったに違いない。
みながわ氏は残念ながらそこまで到達しなかったのだろう。それ自体は悪いことではない。まずかったのは「自分が理解できないもの」＝「使えないもの」と短絡的に思い込んでしまい、なおかつそれを公言してしまったことだ。しかも@ITという技術サイトのコラムでである。
タイトルは失念したが「相対性理論は間違っている」というテーマのエセ科学の本を読んだことがある。著者が相対性理論を否定している理由は「考えてみたが理解できなかったから」というものである。確かに一般相対性理論はとてつもなく難解だが、特殊相対性理論は中学生レベルの数学が理解できれば難なく理解できるというのに。
みながわ氏の一連の発言を読みながら、この本のことを思い出したのは言うまでもない。
退散する、と言っておきながら失礼しました。
山無駄
どうも AC/DC様 おはようございます。
確かに現在、オブジェクト指向に基づいたソフトウェア開発は定着してますね。
制御系や組込系の世界でも、当たり前になってきているのではないでしょうか。
でもここまで普及するには決して平坦な道のりではなく、オブジェクト指向の
考えが生まれてから普及定着するまでには結構な時間がかかったように思いま
す。
十何年前には、まだオブジェクト指向という言葉が流行りだした時期で、開発
会社の営業さんがユーザ企業にオブジェクト指向という新しい技術があるから、
という様な営業をかけ、それにユーザ企業が飛びついたものの、まだ技術者が
未熟だったり、道具がそろってなかったり、マシンスペックが低くまともに動か
なかったりと痛い目を見たユーザ企業が結構いた様に思えます。
実のところ我々もJavaが出始めの頃、サーバサイドで動くすごい技術があると
飛びつき、インスタンス化の意味もまともに分からないまま、それこそ全てStatic
変数で開発し、別の誰かがログインしたとたん全て同じログイン者になってしま
う、という様なシステムを開発してしまった経験があります。その時のお客様は
物分かりがよく、苦笑いして許してくれましたが。
そんなこんなで昔、痛い目にあったユーザ企業中にはオブジェクト指向に対して
拒否反応を示す方もいらっしゃるのは事実です。今はもう少なくなったでしょう
けど。
ただトラウマがあるからと言って、件の相対性理論の作者の様に否定してよい、
という訳ではありませんね。何事も少しでも正しく理解しようとする努力は、技
術者や科学者としての義務ですもんね（その作者が科学者かどうかはわかりません
が）。
山無駄さんこんにちは
>そんなこんなで昔、痛い目にあったユーザ企業中にはオブジェクト指向に対して
>拒否反応を示す方もいらっしゃるのは事実です。
>今はもう少なくなったでしょうけど。
GUIベースのアプリケーションだらけなので、そいいった意味でオブジェクト指向は当然ということでユーザー企業には受け入れられてます。しかし、
>山無駄さん 2010年8月24日 (火) 12:29
>確かに表記法であるUMLなどを使うことはほとんどありません。
>ビジネスデザインをUMLで記述する、
>という考え方もあるようですが、お客様に理解してもらうに壁があるのです。
これについて「なんでだろう？」という深い考察をしてみたらいかがでしょうか？
これについて考察することが、山無駄さんが言っているところの
「先人たちの叡智を少しでも正しく理解し、そして自分たちの知恵も加え、また次の世代に伝えるのは、今の技術者達の責務」
だと私は思います。
＞それこそ全てStatic変数で開発し、
＞別の誰かがログインしたとたん全て同じログイン者になってしまう
オブジェクト指向トラウマの逆、staticトラウマとも言えませんか？
staticを使って昔失敗したから、staticと聞いただけでもダメっていうトラウマ。じゃあ、「なんでstatic はあるのか？」 考えてみるのが次の世代に正しく知識を伝えるための責務だと思いませんか？
実は私はユーザー要件定義はＤＯＡ的な手法で行ってます。慣れているユーザーは逆にユーザーの方から「このデータの紐付け大丈夫ですか？」なんて言ってきます。
現在の技術は、オブジェクト指向、ＤＯＡ、構造化プログラミング、ＷＥＢアプリーションなどテクニックが共存した状態です。それらを適切に使い分ける指針を示すことが重要だと思います。
flatline
こんにちは。
本当はこういうことを言うと、余計にあおることになるのかもしれませんが。
> これについて「なんでだろう？」という深い考察をしてみたらいかがでしょうか？
みながわさんが、したり顔で言うべきことではないと思います。
深い考察が必要なのは、みながわさんですよ。
>じゃあ、「なんでstatic はあるのか？」考えてみるのが
みながわさんにこそ考えていただきたいです。
なんでstatic はあるのか。いつ使うべきで、これが重要ですが「いつ使わないべきなのか」。
私は人間ができているので、みながわさんのためを思って親切で言いますが、みながわさんがオブジェクト指向に関して何か言うたびに、ネット上で失笑されるだけですよ。SE WORLD の8/18付けの近況を読んで、あちこちでいろいろ言われているのをご存じないのでしょうか？承知しているけれど無視しているのでしょうか？
まず、ご自分の狭い経験だけを前提にした「上から目線発言」を控えてみてはいかがでしょう？
山無駄さん、またまたコメント欄を汚してしまいました。
ごめんなさい。
山無駄
どうも。みながわけんじ様
>GUIベースのアプリケーションだらけなので、そいいった意味でオブジェクト指向>は当然ということでユーザー企業には受け入れられてます
まあ、そうですね。私の周りのお客様の間では、Javaなどのオブジェクト指向言語
での開発はすっかり当たり前になってしまい、オブジェクト指向云々という事が話
題にのぼることは殆どないです。それはある意味、ユーザ企業に認知された、とい
う事なのでしょうね。
>これについて「なんでだろう？」という深い考察をしてみたらいかがでしょうか？
そうですね。基本的にはUMLという表記方法とUMLで何を表記しようとしているか
（表記しなければならないか）というオブジェクト指向の基本的な考え方が、まだ
お客さまにとって馴染みがなかった事が一番の理由だと考えております。
今は、ユーザ企業さんによってはUMLを使える、オブジェクト指向の考え方が分か
っている、お客さまもいらっしゃいますが中小のお客さまなどは、UMLやオブジェ
クト指向どころか、システムって何？ITって何という方も多くいらっしゃいます。
なので、私個人は別にお客様と対峙する際にUMLやオブジェクト指向にこだわる必
要はなく、お客さまに応じた形でシステムを表現すれば良い（その中の一部として
UMLの表記があっても良い）、というスタンスです。
なので、お客様へ、本当にお客様の役に立つにシステムを提案や企画したいと思う
のでオブジェクト指向やUMLなどを個人的には勉強し正しく理解したいと持ってい
ますが、お客様にはそのお客様にあったかたちでできるだけ分かりやすく表現する
ことを心がけているので、UMLは普段あまり使っていない、という表現をしました。
>オブジェクト指向トラウマの逆、staticトラウマとも言えませんか？
>staticを使って昔失敗したから、staticと聞いただけでもダメっていうトラウ
>マ。
うーん。私がトラウマと言っているのは、AC/DCさんが先のコメントで「今はオブ
ジェクト指向がベストプラクティスだ」と表現されていたので、確かに今はそうか
もしれないけど昔は、技術や道具が未熟であったために開発がうまくゆかず、開発
側がお客様に迷惑をかけた事例もありますよ、だから必ずしも全員がベストプラク
ティスだと思っているわけではない、というアンチテーゼを書かせていただいただ
けで、まあそれをstaticトラウマと言ってしまえば、それはそうなのかもしれませ
んね。
>じゃあ、「なんでstatic はあるのか？」 考えてみるのが次の世代に正しく
>知識を伝えるための責務だと思いませんか？
ここについては、同感です。昔は知識が足りず訳も分からず全てstaticを使って
失敗した経験はありますが、今はそこを反省してちゃんとstaticやインスタンス
の意味を踏まえ、なるべく適切なところに適切な使い方で開発していると思います
よ（残念ながら私はコーディングはしないもので、我々の開発部隊が、という意味
で）。もしかしたらシステムの要件によっては、また全てstaticのシステムなんて
いうのも開発する機会があるかもしれませんね。
>それらを適切に使い分ける指針を示すことが重要だと思います。
それはその通りです。私どものソリューションパッケージも、サーバーサイドは
Javaですが、クライアントは.NETです。またPasori、HTや携帯もあるので、専用
の言語やドライバ用のC、それにアクセスするためのActiveXなども混在します。
開発開始当初は会社から、ひとつのパッケージを作るのだからサーバーサイドとク
ライアント側をな、Javaか.NETで統一しないのか？と文句を言われたものです。で
も、でもこのシステムを使う人や、場所、目的などを考え、各技術の特徴などを鑑
みると、やはりその組み合わせが最適と、会社を説得しました。
会社は技術を分けることで、生産性が落ちることを懸念してた様ですが、技術者は
マルチな技術になることを苦にした風もなく、生産性も落ちることなく、多能工化
しております。
開発の本質は、意外と変わらないのかもしれませんね。
ハムレット
こんにちわ。
＃ちと現実逃避中だったりします。{^^;）
山無駄さん>個人的には、道具・方法論としてのオブジェクト指向も大切ですが、もう少し思想
山無駄さん>としてのオブジェクト指向を議論しても良いかな、と感じております。お客様の混
山無駄さん>沌とした業務を整理する際、もしくはシステムを０から企画する際に、とても重要
山無駄さん>な考え方となります。
そうですね。現代哲学の主なテーマに言語論があります。その中に「人はなぜ言葉を使って同じ物や概念を共有できるのか。」って課題が有ります。
ただ共有の度合いや範囲も、民族や言語、対象の抽象度に色々と異なるので、そういった認識の構造みたいなところを、考えるみたいです。たとえば虹の色が民族によって異なるのはなぜという所から始まって、例えば「甘える」という動詞に相当する概念は実は英語に無くて、その意味を表現するにはどうしたらよいかとか。色々と応用例はたくさんあります。
システム開発の工程もより上流に行けば行くほど、より抽象度が増えるのですが、そう言った状況では、「思想としてのオブジェクト指向」という哲学的な側面がより問われる事になると思います。
例えば、同じような業務でも、会社が違えば、文化やルール、経営者のポリシー等によって、全然違った形になりますよね。それは同じ会社内でも、部署が違えば、同じ概念を違う言葉で表現していることって多々あると思います。
会社間の合併や組織再編に伴う業務システムの統合なんてシステム開発案件は最近増えつつあるように思えますが、先に述べた組織間の文化的、習慣的な理由による業務手順のギャップをどう解消するのか重要な課題になるとと思います。
こう課題を先送りせずに、上流できっちり整理して、要件として提案するには、やはり業務モデルの再構築が必要になります。こうした課題を先送りにすると、結局、継ぎ接ぎだらけのバベルの塔のようなシステムとなると思います。また「デスマーチプロジェクト」の原因の多くが、こうした上流工程ですべき要件の整理や整合性の確保が不十分で、後で矛盾が発覚して仕様変更が多発して火を吹くといったケースが多いと思います。
そうした業務モデルの再構築の為の方法論として「オブジェクト指向」は非常に強力な武器になると思います。但し、クラスベースのオブジェクト指向だと、表現しきれないこともあるので、その辺はオントロジーモデルを使ったりする場合もあるでしょう。但し「思想としてのオブジェクト指向」に対する理解が有れば、オントロジ－の理解もその延長線上だと思います。
山無駄
どうも flatline様。こんにちは。
うーん、ごめんなさい。先に宣言させていただいた通り、コメントは控えさせて
いただきます。
本日編集者から、コラムに関係ないコメントもあるようなので削除するかどうか
問い合わせがありました。
私個人の考えとしては、直接はコラムに関係ない内容かもしれないが、全く関係
ないのではなく何らかの理由があって皆さんコメントを書いてくれているはずな
ので、できれば残しておきたい旨、伝えました。
ただどうしても個人への中傷や攻撃となり、その人に対して迷惑がかかるようで
したら削除するしかないとも思っております。
できればせっかく皆さんの関心が高いテーマの様ですので、趣旨にご理解いただ
き建設的な議論、コメントをいただければ幸いです。
山無駄
どうも。ハムレット様
>＃ちと現実逃避中だったりします。{^^;）
いやあ、現実逃避中の方にこれだけのコメントは書けませんよ。
現実逃避中だから、書ける？
冗談はさておき。
上流工程での品質の作りこみ、とのご意見。はげしく同感です。かつ、ここが我々
が今取り組んでいる最大のテーマだったりします。
現在我々のミッションは、中小の工事会社向け全社最適システムの開発と展開で
す。
計画当初、まず言われたことはウチは隣の部門とはまったく違っていて、別会社
見たいなものだ。だからシステムも絶対に同じにならない。
しかし業務内容をヒヤリングしてゆくと、確かに工事の規模や対象や管理粒度は
異なるものの、やっている事は（本質的に）同じ。
なので、結局経営者を説得し全社共通のシステムとして開発しました。各部門の
差異を最小公倍数として実装するのではなく、基本形を継承させた形での実装と
して。これが、結構うまく行きました。基本的にはやることが多少違っても同じ
会社なのでしょう。
次にこのシステムを、問題解決のノウハウ付きで同業他社に展開しようとしま
した。その際にもまず言われることは、ウチの会社の問題はカクカクシカジカ
で。これはウチ特有の問題なんですよ。
でもそれは、初めて聞く内容ではなく、前の会社でも同じ。言葉や、切実度は
違うかもしれないけど。業種特有の悩み、というのもあるのでしょう。
そういった事があると、ハタと気づかされます。
物事を抽象化して考える、という事を確かにオブジェクト指向は言っている。
…この辺りの議論、きちんともう一度コラム本編で取り扱いと思っております。
なのでココで色々と書いてしまうと、ネタが尽きてしまうので、今日はこの辺に
て。
flatline
すみませんでした。反省しています。
AC/DC
山無駄さんも、ズレまくってるみながわさんに、いちいち丁寧にお返事することないのに。
まあみながわさんに何言ってもムダなのでこれぐらいにしとこうか。
ここからは、まじめモードで。
おそらくみながわ氏を代表とする「オブジェクト指向は実務では使えない」と主張する人々（ごく少数であることを祈りたいが）が誤解しているのは、オブジェクト指向がプログラミングの一手段に過ぎないということではないかと思う。
オブジェクト指向は、たとえばstaticをどう使うとか、抽象クラスとインターフェースはどう使い分けるかとか、そういう細かいことばかりではなく、システム分析・設計フェーズから「思考」することによって、開発工程そのものを劇的にわかりやすく簡素化することができる、ということがわかっていない。
自分もたまに同業他社のエンジニアと仕事をすることがある。たいていはシステム丸ごとではなく、サブシステムとか切り出せる機能単位で渡すのだが、優秀なエンジニアだときちんとインターフェースと具象クラスに分けて実装してくれる。JavaDocがきちんと記述された適切な名前のインターフェースは、使っていて安心感がある。DIコンテナがあれば具象クラスがなんなのかすら意識する必要がなくなる。ファクトリを使えばif と else のスパゲティから解放される。
みながわ氏は、先のコメントでなぜインターフェース（または抽象クラス）を使うのか理解できないと書いている。確かにオブジェクト指向をプログラミングの一手段にすぎないと信じている間は絶対に理解できないだろう。
最初は誰でもそこからスタートする。そして多くのまっとうなエンジニア諸兄はオブジェクト指向の持っている可能性に気付き、なぜインターフェースを使うのかを理解するに至る。移り変わりの激しいこの業界で、なぜオブジェクト指向がかくも長い間生き続けているのか、その理由を知ることになる。やがて、実務に使えないどころか、オブジェクト指向を使わないシステム開発など考えられなくなってくる。
オブジェクト指向で「思考」することによって、システム開発は劇的に変わる。それもエンジニアにとって喜ばしい方向へ。民主主義がそうであるように、オブジェクト指向は先人達が苦労して積み重ねてきた知識の遺産であり、我々が維持し改良し、後継者へ引き継ぐべき財産である。
理解できないのであればそれでもいい。
しかし、どうか「自分が理解できないものは使い物にならない」と決めつけないでほしい。決めつけてもかまわないが公言しないでほしいと思う。これからこの業界に入ってくる人たちのために。
こんにちは。コラムニストの中越と申します。
（ずっと投稿していないので幽霊部員ですが・・・）
私はふだんJavaなどの研修講師をしていますので、オブジェクト指向の入門みたいな講義もよくやります。
例がどうしても人とか動物とか車とかになってしまうのは、例示としてのイメージのしやすさというのがあると思います。やはり即物的な「モノ」のほうが誰でもそのイメージを想起しやすく、なおかつ仕様について説明する必要がほとんどない（「ヒト」が「名前」「年齢」という状態を保持する、といってその意味を誤解する人はほとんどいない）ので伝えたい核心から話題をそらさず（周辺の説明を多くし過ぎず）に概念を伝えられるというのが説明する上ではメリットになると思っています。
実際的なシステムを題材に、その一部を例として取り上げる場合、「システム」というものがそもそも即物的ではないので、どうしても概念的なクラスについての説明になりがちです（題材の選び方にもよるとは思いますが）。そのため、説明を受ける人にとってイメージがしにくい＝実際的なシステムの仕様についてある程度理解してからでないと例の内容が理解できない、という教える上での手間の問題が出てきます（手間を惜しむわけではないですが、遠回りが多くなってしまうと注力すべき問題がぼやけてしまうと思うのです）。
とはいえ、即物的なモノで説明して終わり、ではやはり実際のシステム開発の内容と隔絶してしまうのも事実です。理想は、イメージしやすい即物的なモノで概念の確信に近いところを理解し、さらに実際的な題材でそれを応用する、という感じでしょうか。
山無駄
どうも。flatline様
趣旨をご理解いただきありがとうございます。
個人に向けた話より、もっと幅広い人に向けた議論をしてくれると嬉しいです。
山無駄
どうも。AC/DC様
オブジェクト指向で「思考」。良いですね。
以前のハムレットさんとの議論ではりませんが、私はオブジェクト指向は人間が
世界をどの様に認識するか、という事を形式知化したものだと考えております。
これは言いかえると、オブジェクト指向がオブジェクト指向という名前をもらう
前から人間は暗黙知的にオブジェクト指向的に物事を「思考」していたのではな
いかと。
あくまでも仮説、私の想像の域を出ないことではありますが、おそらくソフトウ
ェア開発の世界にて、まだオブジェクト指向というものが認識されていない時代
においても業務設計、システム設計のフェーズではオブジェクト指向的な「思考」
がなされていたのではないかと。しかしその時代はまだ道具（コンピュータや言
語）が未熟ですので、一度現実世界の認識を、コンピュータの世界にコンバート
する必要がありました。これがいわゆるプログラム設計と呼ばれるフェーズです。
ところが物事の認識の仕方の暗黙知が「オブジェクト指向」として形式知化され
ると、道具の方もそちらに合わせてゆく方が、人間の認識とコンピュータの世界
との間におこる断絶やコンバートを生み出さなくて効率的だ、という考えになり
オブジェクト指向言語といわれるものが世の中に産まれたのではないかな、と。
道具が人間の認識と近くなったことで、上流の設計工程とコーディング工程が
シームレスとなり、品質の向上や生産性の向上やシステムの大規模化の実現につ
ながった。これがオブジェクト指向の教科書でもよく見かける、オブジェクト指
向のメリットですね。加えてハードも進歩し、冗長化した言語に対しても十分に
耐えうるようになった。
これが、AC/DCさん以下ののコメントに対する私の解釈です。確かに手段として
のオブジェクト指向もあるが、「思考」としてのオブジェクト指向もある。全く
の同意です。
>オブジェクト指向がプログラミングの一手段に過ぎないということではないかと思
う。
>システム分析・設計フェーズから「思考」することによって、開発工程そのものを
>劇的にわかりやすく簡素化することができる
でも正直、最近はこれだけの解釈では足りないのではないか、という気がしており
ます。オブジェクト指向が人間の認識の仕方を形式知化したものであるとして、じ
ゃあ世の中を認識しそれを表現する方法を持てば、それだけでシステム開発は品質が向上し、効率化され、大規模化できるのか？？？？
例えば８色しか表現できないペイントツールから、フルカラー表現できるペイント
ツールに変わったとして、これで世の中の色は全て表現できるはず。それで、世の中のどんな絵でも描ける様になるか？みたいな疑問です。
おそらく答は否で、絵の描き方を知らないと絵は描けません。これと同じことがシ
ステム開発の世界にあり、オブジェクト指向で世の中を表現できる事は出来るよう
になった。しかし「設計」をきちんとしないと、システムの品質は悪くなるし、
生産性は落ちるし、大規模システムはごみの集まりになる、かもしれません。
オブジェクト指向の教科書がよくわからないのが、この「設計」の概念を無視して
例示を行うから良く分からなくなっている様な気がします。じゃあ、新人に設計の
説明までするか、というとこれまた、辛い気がしますが。。。
因みに「設計」というものを初めて学問（設計学）として取り扱ったのは元東大
総長の吉川弘之氏らしいです。当時、「設計」なんていう経験や勘の世界のものを
学問で取り扱う事はできない、と周りから相当言われたらしいですけど。…全くの
余談でした！
山無駄
どうも。中越 智哉様 はじめまして。
うーん。やはり例示には即物的な「モノ」で構わないのではないでしょうか。
「システム」なんぞ、こんなに分かりにくく曖昧なものはありません。
「魚屋は、魚とはどんなものか知ってるだろ？八百屋は、野菜がどんなものか知っ
てるよね。お前ら、罷りなりにもシステム屋だよな。じゃあ、システムっ何？」
そんな嫌がらせな質問をして、若い連中に嫌な顔をされたことが何度かあります
（私も若い連中の一人ですが）。
ただでさえオブジェクト指向も分かり難いのに、これにシステムが絡めば余計に分
からなくなります。
冗談はさておき。
個人的には、オブジェクト指向の教育の中で取り扱う例示は、即物的な「モノ」で
あろうと仮の「システム」であろうとなんでも構わないと思っております。
それよりも、そのオブジェクト指向教育の中で、何を教えようとするのかをもう少
し議論をした方が良いのではないかと。
オブジェクト指向言語での開発者を育てようとしているのか、オブジェクト指向の
「思考」を身につけさせようとしているのか、オブジェクト指向での表記方法をマ
スターさせるのか。
オブジェクト指向での「思考」を身に着けさせようとするなら、あまりシステムに
こだわらない方が本質の議論ができるでしょうし、オブジェクト指向言語での開発
者を育てようとするなら、より実践的な「システム」の例題が良いかもしれませ
ん。
私の持っている教科書の問題なのかもしれませんが、どうも教科書の中身を見る限
り何を目指しているのかよくわからなく、どれもが中途半端になっている気がして
なりません。本コラムで（ささやかな）疑問として提示させていただいた内容もそ
うなのですが、他にオブジェクト指向を使うと品質や生産性が向上する云々。とさ
らっと書いています。間違いではないのかもしれませんが、そんなにステレオタイ
プで良いのかな、と。
望むらくは、例示にはこれは何を表現しようとしているか、という定義を明確にす
る。そして、例えば「ヒト」が「名前」や「年齢」をパラメータを保持する、とい
うだけでなく、では「身長」や「体重」などはどうか、加えて「血糖値」「コレス
テロール」「尿酸値」はどうか加えて「髪の毛の本数」「虫歯の数」「皮膚の色」
など、色々と議論してみてはどうでしょうか。
すみません。私の勝手な意見です。
山無駄
皆々様
色々なご意見ありがとうございました。
有意義な議論ができ、私の頭の中もかなり整理できたような気がします。
普段は200アクセス位しかないのに、本稿が公開されるやいなや1,700アクセス
ぐらいに跳ね上がり、とても驚きました。そんなに盛り上がるネタとは思ってな
かったもので。。。それとコメントの速さ。
今週は仕事に少し余裕があり対応ができたのですが、来週は出張等が重なってお
り殆ど、返事を書くことができないと予想されます。ご容赦ください。
できれば今回の議論を改めて、コラムの本稿で纏めてみたい、と考えております。
その際には皆様から頂いたコメントを参照させていただくかもしれません。
お許しください。そして、その時にまた色々と議論させていただければ、と思っ
ております（その時は、お手柔らかにお願いします）。未来を担う後輩たちの、
少しでも有益な肥料となるように願いつつ。
あと、他のコラムにもコメントいただけると嬉しいなぁ。
山無駄さん＞
>それよりも、そのオブジェクト指向教育の中で、何を教えようとするのかをもう少
し議論をした方が良いのではないかと。
>オブジェクト指向言語での開発者を育てようとしているのか、オブジェクト指向の
「思考」を身につけさせようとしているのか、オブジェクト指向での表記方法をマ
スターさせるのか。
おっしゃるとおりですね。
何かを学ぶ、教える、スキル習得の全般に言えることですが、ゴールが曖昧だとミスマッチになってしまいます。
議論というよりは、それぞれの書籍なり研修なりが、そのゴールを明確に示しておくべきですね。そうすれば、学習者もある程度自分で選択できますよね。といいつつ弊社の研修メニューにはそこまで示せていないなぁ・・・反省です。
山無駄
中越 智哉様 おはようございます。
>議論というよりは、それぞれの書籍なり研修なりが、そのゴールを明確に示してお
>くべきですね。そうすれば、学習者もある程度自分で選択できますよね。といいつ>つ弊社の研修メニューにはそこまで示せていないなぁ・・・反省です。
研修という限られた時間の中で、全ての研修生がメニューに対して100％を達成す
ることは難しいですよね。研修を依頼する企業も、研修生のゴール達成率でその研
修メニューを評価するのか、それとも研修生のゴール達成率ではなく、どこまで高
度な知識やスキルを身につけたか、という最大習得値？で評価するのか、という所
でも研修のゴール設定は変わってくるような…。
根拠はなく個人的な感覚で申し訳ないのですが、どうも上記前者（どこまで深く勉
強したか、ではなくゴールの達成率での評価）を意識した研修や参考書籍の方が比
較的に多く存在するように思えます。
できれば、本質論を学べるような、もしくは（興味や余裕がある人は）本質論の議
論へ進めるような、研修や教科書があればいいなぁ。
頑張ってください。
Fufuhu
急に議論に飛び込んできて失礼します。
自分の通ってる大学の教授（情報科学方面の）がおっしゃっていたのですが、
オブジェクト指向でインターフェースをしっかりかけるのは作成したいソフトウェアが明確になっている、すなわち上流工程がしっかりできている証拠で、「純粋なプログラミング的な能力を考慮しなければ、インターフェースがかける＝クラスもかける」と解釈して良い的な話をされていたのですが事実でしょうか？
AC/CDさんのおっしゃるように、具象クラスがしっかりしていて、その上でインターフェースまで実装されているなら、具象クラスの中身までは気にせずにブラックボックス的に扱えるから楽ってのは分かります。
オブジェクト指向とは少々ずれた話になるのですが、JavaのSwingでJFrameを利用してGUIを作成するのとC++を使ってWindowsAPIを叩いてGUIを作成するのだと自分は前者を選択したくなるので（動作条件がシビアなら後者を選択しますけど）
オブジェクト指向を学生的なポジションで言うと
「楽をするための手段」
ってな具合に解釈すると理解しやすいかもしれません。
（学習コストが異様にかかるのが問題ですが…）
オブジェクト指向って完成した姿をきっちりと定義しないといけない。
つまり上流工程がしっかりとしていないといけないので、よほどの優秀な人でない限りは難しい…自分も自作のソフトウェアを趣味で作る際に完成図をしっかりと想像してそれを個々の要素に分割していくってのは重要だと思いましたから。
あと塾講師のバイトを数年している身からすると
「学び方を教える」方が効果は上がる感じです（本人にやる気があれば）。
授業だけでは生徒の能力は絶対に伸びませんから。
山無駄
どうも。Fufuhu様 はじめまして。学生さんですか？
>オブジェクト指向でインターフェースをしっかりかけるのは作成したいソフトウェ
>アが明確になっている、すなわち上流工程がしっかりできている証拠で、「純粋な
>プログラミング的な能力を考慮しなければ、インターフェースがかける＝クラスも
>かける」と解釈して良い的な話をされていたのですが事実でしょうか？
「ソフトウェアが明確になっている」という言葉の意味合いによりますが、私は「曖昧な部分や、変化する部分も含めて」という風に解釈したいですね。本当に
曖昧な所もなく、将来変化する可能性のないソフトウェアを開発するのであれば、
別オブジェクト指向でなくても良いかもしれません。何故ならオブジェクト指向は
「変化に強い」というメリットがあります。
私は経験がないのでもしかすると都市伝説化もしれませんが、昔、ゲームソフトの
開発は一度高級言語で行った後、アセンブラで書き直している、という話を聞いた
ことがあります。昔はハードのスペックが高くなかったのと、コンパイラの最適化
が未熟だったことがあり、高級言語で開発して仕様を確定したのちに、アセンブラ
で書き直して容量とパフォーマンスを最適化する、というのがその理由でした。
翻って業務システムの開発などを考えてみるに、最初の段階で、完璧にソフトウェ
の仕様が決まるという事はほとんどなく、今は曖昧なまま進めなければいけない、
将来の変化を織り込まなければならない、という事はざらに起こります。
「企業の本質はマーケティングとイノベーションである」という言葉の通り、業務
が変わることは前提としないといけませんし、システム側もそれに追従することが
求められます。今後の変化が予測されるところ、今は曖昧でしょうがないところ、
ここはしっかりと決まっており不変的な所、という様な事を見極めるのは上流工程
の役割ですし、それら踏まえてプログラムをしっかりと設計しないといけません。
その設計の中で、インターフェースをどう使えば良いかが決まってきます。
これら踏まえ、教授は「上流工程がしっかりしている証拠」という表現をされたの
かもしれませんね。
>オブジェクト指向を学生的なポジションで言うと
>「楽をするための手段」
>ってな具合に解釈すると理解しやすいかもしれません。
>（学習コストが異様にかかるのが問題ですが…）
オブジェクト指向に関わらず、物事を理解することに「学生的なポジション」とか
「社会人的なポジション」とかあるのかはよく分かりませんが、「楽をするための
手段」と決めつけてしまう事は危険だと思いますよ。
それより学生さんだからこそ学習コストなど気にせずに、時間をかけてでも本質を
しっかり勉強してもらいたいと思います。勉強に無限に時間をかけられるのは、学
生の特権です。
>つまり上流工程がしっかりとしていないといけないので、よほどの優秀な人でない
>限りは難しい…自分も自作のソフトウェアを趣味で作る際に完成図をしっかりと想>像してそれを個々の要素に分割していくってのは重要だと思いましたから。
うーむ。「上流工程をしっかりするのは、優秀な人でないと難しい」というのもど
うかと思います。まず上流工程と下流工程の違いは、時間軸と役割分担の問題で
人の優劣ではないのが一点。上流工程である、業務設計や、システム設計などにも
優秀な人やそうでない人もいますし、下流工程であるコーディングやテスト、運用
についても優秀な人もいれば、そうでない人もいます。というか、そもそも何が上流でどこからが下流か、という事すら定義はあいまいです。
それと「しっかりする」のが優秀な人かというとそれも疑問で、お客さまからお金
をもらって仕事をする限り、優秀であろうがそうんでなかろうが、「しっかりする」のは当たり前だと思います。
ただ、どの工程であれ、同じ事をするに他の人と比べて作業が極端に早い人、もし
くは、他の人が思いつかない様なやり方を思いつく人、もしくはチームの雰囲気を
明るくする人などが居ます。こういう人は「優秀な人」といってよいかも知れませ
ね。
>「学び方を教える」方が効果は上がる感じです（本人にやる気があれば）。
>授業だけでは生徒の能力は絶対に伸びませんから。
あと、「何を何のために学ぶのか」を教えるのも良いかも知れませんね。手段で
はなく目的を教えるのも大切だと思います（塾の役割ではないのかもしれません
が…）。
頑張ってください。
Fufuhu
山無駄さん、ご返事ありがとうございます。
はい、来春からIT業界で働く予定の大学院生です。
>曖昧な所もなく、将来変化する可能性のないソフトウェアを開発するのであれば、
>別オブジェクト指向でなくても良いかもしれません。何故ならオブジェクト指向は
>「変化に強い」というメリットがあります。
の部分ですが、基本的にいったん作成されたソフトウェアというのは利用者が要るか義理はバグフィックスや改修を受けつづけると考えているのでオブジェクト指向が現状はベストなのかなと考えています。
C, Perl, Javaを状況に応じて使い分けているのですがCやPerlで書いたプログラムを改修しろと言われるとウヒャーとなってしまうことが多々あるので。(Perlでオブジェクト指向はできるだろというのはさておき）
Javaなら改修内容さえはっきりすれば改修対象の切り出しが容易なので作業がスムーズに進む感覚はあります。
>「楽をするための手段」と決めつけてしまう事は危険だと思いますよ。
すみません、言葉足らずでした。複数人で作業を薦めるに際してソフトウェアを部品として切り出すことが容易になると思ったので…
オブジェクト指向を使わずに作ったプログラムと使ったプログラムでは他人に引き渡す際の説明が後者の方が少なくすんだので楽でした。
オブジェクト指向で作ると機能の切り分けがある程度できているので、全体の作りを説明しやすかったんです。
>それより学生さんだからこそ学習コストなど気にせずに、時間をかけてでも本質
>をしっかり勉強してもらいたいと思います。勉強に無限に時間をかけられるの
>は、学生の特権です。
一応は情報工学系の学生ということになるので、
時間が許す限り広い範囲の知識を身につけて社会に出るのに備えたいですね。
私が「上流工程はよほど優秀な人たちでないと無理」と述べたのは少々主観的に過ぎたのかも知れません。コストと時間、品質のバランスを考えながらシステムの全体像を固めていくというのが、バランスをとることが苦手な私には他の事柄よりも困難に思えたので…
すみませんでした。
山無駄
どうも。Fufuhu様
>基本的にいったん作成されたソフトウェアというのは利用者が要るか義理はバグフ
>ィックスや改修を受けつづけると考えているのでオブジェクト指向が現状はベスト
>なのかなと考えています。
基本的に、完成ソフトウェアに何処まで手が入るかは、対象となるソフトウェア
の目的と、お客様との契約によって決まってきます。
また完成するまでにも、機能要件の決定が遅れたり、仕様が変わったりします。
またアジャイルの様な開発方法を使うと、ソフトウェアはずっと変化することに
なります。そういった場合には確かにオブジェクト指向にもとづく開発は、有益
な選択肢となることでしょう。
ただし気をつけなければならない点も多々あります。例えば…
１．世の中の全てのソフトウェアが、変化を受入れ必要があるとは限らない
一度作ったら二度と改修できないソフトウェア。とても貧弱なスペックのハ
ード上で動かさなければならないソフトウェア。ずっと使うのでは一時期の
み必要なソフトウェア。等々。これらのソフトウェアを開発する際に、必ず
しもオブジェクト指向に基づく開発が最適かどうかは疑問です
２．オブジェクト指向に基づいたからと言って変化に強く品質の良いソフトウェア
が開発できるわけではない
例えばオブジェクト指向の変化に強い理由として、ポリモーフィズム等の理
由が挙げられますが、それはポリモーフィズムを正しく理解し、適切に使っ
て初めて実現できるのであって、変な使い方をすると逆に変化に弱くなって
しまう事もあります。また品質や生産性向上の話のなかに、「再利用性」と
いう言葉も出てきますが、これも同様のシステムを他に作る予定があり、ま
たそれらのノウハウを蓄積できて初めて可能となるのであり、一度きり、初
めてのソフトウェアを開発する際には必ずしもその限りではありません。
大切なことは、お客様の欲しているものは何かを理解すること。その要求を満た
すシステムはどういうものかはっきりすること。そして、そのシステムを構築す
るのに最適な技術を選定する事だと思います。
一番よろしくないことは、自分がJavaしか知らないからと言って、お客様が求
めている貧者なハード上で動く高速なソフトウェアの開発に、Javaを使ってし
まう事だと思います。
>コストと時間、品質のバランスを考えながらシステムの全体像を固めていくという
>のが、バランスをとることが苦手な私には他の事柄よりも困難に思えたので…
ここの話は、上流工程に限った事ではないと思います。我々はこれらの例示とし
て、よく「エキスパート」と「プロフェッショナル」という表現を使ったりしま
す。「エキスパート」とはその技術の専門家で、高度なスキルを持ち、どんなに
難しい（技術的な）問題も即座に解決してしまいます。加えて「プロフェッショ
ナル」とはコスト、納期、品質等を考え最適な方法で仕事をこなす人の事を言う
のです。どんなに射撃の腕が良いからと言って、それだけではゴルゴ13にはなれ
ない、ということですね。
>はい、来春からIT業界で働く予定の大学院生です。
>一応は情報工学系の学生ということになるので、
>時間が許す限り広い範囲の知識を身につけて社会に出るのに備えたいですね。
昨今、学生の人気が落ちたといわれるこの業界。優秀な方が入ってきてくれるの
は大歓迎です。
最後に老婆心ながら付け加えさせていただけるなら、「幅広い知識」に加えて「
本質を真剣に考え抜く」という力を身につけた方が良いですよ。社会人になって
も（社会人になった方が）色々な知識に触れる機会が多いです。でも代わりに日々
の仕事に追われ、真剣に考え抜く、という余力がなくなってしまう様な気がしま
す。私の経験則で申し訳ないですが。
ひろし
議論をナナメ読みした限りでは、
ArrayList userNameList = new ArrayList();
とするよりも
List userNameList = new ArrayList();
とすべきであるという具体的な理由が述べられていなかったようなので、
さしでがましいようですが、解説します。
さて、変数の型に関して抽象度を上げる理由は、開発のモジュラリティを
高める。これに尽きます。新しく new した ArrayList のインスタンスを
ArrayList型の変数ではなくその親クラスであるList型で受けておくことに
よって、メソッドの利用をListが備えているもののみに限定させることが
できます(非常時にはキャストしてげふんげふん...ですがこれはそもそも
設計の悪さに帰着します)。
このように配慮することにより、ArrayList の提供者と利用者(ここでいう
利用者とは、ArrayList を使用して開発する開発者のことです)を完全に
分離することができます。極端な例を挙げると、あるときArrayListよりも
優れているSuperListなるクラスが開発されたとします。そしてArrayList
とSuperListに継承関係は不幸にも無かったとします(ありがちです)。
このとき、後者で書かれていれば、new するところを
List userNameList = new SuperList();
に書き換えるだけでSuperListに入れ替えることができます。
もしArrayListで受けていれば、ArrayListのメソッドを使っている箇所を
探しまわるハメになるでしょう。
山無駄
みながわけんじさん ひろしさん こんにちは。
ご理解いただきありがとおうございます。
という事で、下記の様に対応させていただきました。
ひろし 2010年9月11日 (土) 16:42 一部変更
みながわけんじ 2010年10月 4日 (月) 16:09 一部変更
ひろし 2010年10月 4日 (月) 23:44 削除
山無駄 2010年10月 5日 (火) 10:25 削除
みながわけんじ 2010年10月 5日 (火) 17:23 削除
ひろし 2010年10月 6日 (水) 07:55 削除
最後の ひろし 2010年10月 6日 (水) 07:55 のコメントについての取扱いに
ついては少し悩みました。
せっかくひろしさんが、ArrayListではなくListの方が良い、という解説をして
くれたので、それに対してArrayListを推奨する方が納得してくれたのか、それ
とも反論があるのか、コメントが欲しいという気持ちはよくわかります。
ただそれが個人に求めるものなのか、ひろく意見を求めるべきなのか、という事
を考えると私は後者だと思います。
なので該当コメントの対応として、2010年10月 6日 (水) 07:55のコメントは
削除させていただき、私の方から代弁として意見を求めたいと思います。
ひろしさん、申し訳ないですが、そういう対応でご理解ください。よろしくお願いいたします。
山無駄
本コラムのコメントの中で、ポリモーフィズムの考え方に従い、
List userNameList = new ArrayList();
と実装するの良いのか、それともそのまま素直に、
ArrayList list = new ArrayList();
と実装するのが良いのか、という議論がありました。
その議論の中で、ひろしさんが、2010年9月11日 (土) 16:42 のコメントで
ポリモーフィズムを使う理由を説明してくださいました。
このコメントに対して、ポリモーフィズム使わない派？の方はどうお考えでしょ
うか。ご意見をいただければ、幸いです。
ひろし
ポリモーフィズム使わない派の根拠はアレなので、
今後いっさいコメントは付かないと思いますよ。
大藤雄久
はじめまして、
しばらく@ITさんにはおじゃましていませんでしたが、『傲慢と偏見』という小説（？）をみつけそこからこちらにお邪魔しています。
私は、ryoというハンドルネームで、例のコメント欄でみながわさんと話をしました。
さて、２年以上前のコラムで、もう、ひろしさんは見ていないでしょうが、このコメント欄を読んだ方に誤解を与えてもよろしくないので、コメントします。
上記のコード例だけでは、ポリモーフィズムすべきかどうか断定できませんが、この場合、ポリモーフィズムしなくてもほぼ問題ないです。
根拠ですが、『Effective STL』の第2項、『コンテナに依存しないコードという幻想に注意しよう』では、この手（Listクラスで結果を受ける）の抽象化の多くが間違っていると指摘しています。詳しくは書籍を購入して読んでみましょう。
私のブログ（とあるソフトウェアエンジニアのブログ 2012/11/01）にも詳細があります。『傲慢と偏見』に対する記事なので余分な内容もありますが・・・。