＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
オブジェクト指向と現実世界は大違い？
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2005-01-13 13:09
.NET開発者のためのリファクタリング入門についてのつづきです。
──コモンセンスさんの書き込み────────────────────────── コモンセンスです。 脱線するかもしれませんが… 以下の所論についてはみなさんどうお考えになるでしょうか? 私は「いまごろなにを? これだからオブジェクト指向(論者)はおさわがせだ」と思いました。 オブジェクト指向、ホントにあった怖い話(2004/7/10)から >…平澤氏は、オブジェクト指向を巡る混乱の要因は、「プログラミング技術」としての >オブジェクト指向と「汎用の整理術」としてのオブジェクト指向を同一のものとして認 >識しようとする態度にあるとする。 > 例えば、オブジェクト指向の基本解説書や記事では、クラスやポリモーフィズムなど >…を説明する際に、現実世界をそのままオブジェクト指向という考え方を適用して表現 >しようとする。しかし、「オブジェクト指向と現実世界は大違い」（平澤氏）であり、 >オブジェクト指向を正しく理解するには、まず、プログラミング技術として、構造化プ >ログラミングの限界を突破した後に登場した新たな技術として理解することが重要であ >り、主に上流工程における汎用の整理術として応用されるオブジェクト指向とはまった >くの別物としてとらえることが必要だと力説した。 ───────────────────────────────────────── スレッドだけ立てて終わるのもなんなので、私見を書きます。 えーと、今の高校教育はよくわかりませんが、私が高校の頃、物理の授業で塔から球を垂直落下させた時の地面に達するまでの到達時間とか、落下時に生ずるエネルギーとかを、質量と重力加速度から求めたりしました。また、球を斜めに放るとき、30度（でしたっけ？）で放ると最も遠くまで飛ぶとかいうこともやりました。これって現実世界です。でも厳密には現実世界ではないです。なぜなら、現実世界には空気抵抗とか風とか色々な他の要因があり、数式から求めた理論値の通りにはならないから。いわば、高校物理に出てくる現実世界は、現実世界からあらかじめ定義したもの以外の要素を取り除いた、理想的な空間です。厳密に言えば、これは現実世界ではありません。かといって、現実世界を全く引き合いに出さずにこれらのことを説明されたら、ちんぷんかんぷんですよね。 オブジェクト指向に関しても同じことが言えるのではないでしょうか。確かに、「オブジェクト指向と現実世界は大違い」これはある意味正しいかもしれません。しかし、継承とか抽象化とかを説明する時に、ろくにプログラム組んだこともない新人さんにいきなりこのクラスのこのメソッドが…って説明するより、まず「乗り物、自動車、カローラ」と説明した方がずっと理解させやすいですよね？更に言えば、乗り物と自動車とカローラの関係、そしてカローラのタイヤやハンドルやアクセルが、JavaやC#のクラスやメソッドと全く関係のないものとはとても思えません。 だいたい、プログラミング技術としてのオブジェクト指向が、上流工程における汎用の整理術として応用されるオブジェクト指向とはまったくの別物だとしたら、オブジェクト指向を使った一連の工程において、上流工程で作成した成果物はプログラミング工程で全く使い物にならないものなの？ってことになるわけで。 ということで、上記平澤氏の仰ってることは、動機はなんとなくわかるのですが、極端を通り越して大間違いだ、と思いました。 | ||||
|
投稿日時: 2005-01-13 13:27
たまたま、使い物になる場合もあるし、全く使い物にならない場合もある。
確率です。 何故なら、汎用性のある考え方を特定言語の枠に押し込める作業な訳ですから、使えない 部分も出てくる。 | ||||
|
投稿日時: 2005-01-13 14:00
僕は平澤氏の意見に賛成です。
「プログラミング技術として、構造化プログラミングの限界を突破した後に登場した新たな技術」って言ってるのは、主に 手続き型言語では呼び出される側のコード(ライブラリ)を共通化しますが、OOPではそれに加えてポリモーフィズムで呼び出す側のコード(フレームワーク)を共通化出来るということだと思います。こういった重複のないコードを書く、とかカプセル化で呼び出す側のコードが簡潔でわかりやすくなるといったプログラミング技術と、 「主に上流工程における汎用の整理術として応用されるオブジェクト指向」つまりオブジェクト指向分析/設計、業務をオブジェクトとして捕らえて分析設計をしていく技術は別だと思います。 実装のスキルと分析のスキルいうか。実装のスキルはメンテナンスしやすいコードを書くため、分析のスキルは業務を分析してソフトウェアの機能を導き出すためですし、 呼び出す側のコードを共通化することは、「業務をオブジェクトとして捕らえて分析設計をしていく」だけでは、出来ないと思います。ソースコードレベルですよね。 だから別物だと思います。 | ||||
|
投稿日時: 2005-01-13 15:40
＞実装のスキルと分析のスキルいうか。
確かにこういう言い方をしてしまえば別物です。しかし「分析→実装」という流れは、一連の繋がった流れであるはず。両者に関連性が無いのならば、分析の作業など意味ないわけです。 ちょっと例をあげてみます。 オブジェクト指向で分析→手続き型言語で実装 この場合、両者で採用されてる概念そのものが別物なので、矢印は一本で繋がりません。内部的に、オブジェクト指向による分析で構造化されたものを手続き型言語で実装できるように再度分析する、という作業が発生します。では、 オブジェクト指向で分析→オブジェクト指向型言語で実装 この場合はどうでしょうか？矢印は一本で繋がらないでしょうか？繋がるべきですよね。とゆうか、そもそもオブジェクト指向型言語というのはここを一本で繋げるために作られた言語なはずです。 ここで重要なのは、 ＞OOPではそれに加えて この「それに加えて」という部分です。C++はオブジェクト指向型言語の一つですが、同時に手続き型言語であるCのスーパーセットです。そして、JavaやC#など一般的にオブジェクト指向型言語と呼ばれているものもC++の影響を色濃く受けています。現在オブジェクト指向型言語と呼ばれているものは、オブジェクト指向という概念に基づいて0から作られたものではなく、手続き型言語にオブジェクト指向という概念も適用できるように機能を追加したものなわけです。 だから、私は「プログラミング技術としてのオブジェクト指向と一般的な概念としてのオブジェクト指向は別物だ」という表現は誤りであると思います。正しくは、「オブジェクト指向型言語は手続き型言語というオブジェクト指向とは別物の概念によって作られた言語の性質も持っているから、この部分も含めてこれがオブジェクト指向の性質だと思ってしまうのは間違いだ」ということになると思います。 | ||||
|
投稿日時: 2005-01-13 18:28
そうですね、オブジェクト指向は「分析→実装」で一連の繋がった流れ、どの工程でもオブジェクトとして考えることが出来ることが発明だっていう意見がありますよね。
「プログラミング技術としてのオブジェクト指向と一般的な概念としてのオブジェクト指向は別物だ」っていう表現は、「全くの別物」だって言ってるんじゃなくて、別の観点(実装レベルと分析レベルで別)があるから、「まったく同じものだ」って考えると「混乱する」ってことを言ってるだけなんじゃないでしょうか？ | ||||
|
投稿日時: 2005-01-16 13:45
http://www.atmarkit.co.jp/farc/rensai/knowledge09/knowledge09.html
>＠IT > IT Architect > 実行可能な知識とソフトウェア（9） >モデリング＝まねることの本質について この文に限らず、 この筆者であるメタボリックスの山田正樹という人の書く文は いいせん行ってるなあと(私は)思うことがしばしば有ります。 なんといっても、平易な言葉(^^;を上手に使えてるのが、いいなあ。 たとえば上記だと、「まねる」という平易な和語が、すごくビンゴなんですよね。 そうそう。この人は以前の http://www.atmarkit.co.jp/farc/rensai/knowledge07/knowledge07.html というページでも その一番下の段落で、それまでの連載各回を、それぞれ一言で振り返ってるんですよね。 しかも結構的確に。うまいなあ。 てなわけで、この人の会社のwebページは、時折見に行きます。 ＃ところでOpenMDAってどんなんなんだろう？ 閑話休題。 今回のような"現実世界という奴との距離"という問題については、 上記URLのようなとらえ方が、いいんじゃないかと思っています。 | ||||
|
投稿日時: 2005-01-22 19:07
現実世界を定義した瞬間にそれは現実とは異なります。
詭弁と取られるかもしれませんが、 何かを定義するというのは自分の能力のフィルターが掛かる訳であり、 自分が神で無い限り、定義した世界は虚偶の世界です。 「プログラマーは自分の事を神であるかの様に勘違いする傾向にある。」 という文書を読んだ事がありますが、もしかすると、この説が集団的に発生した現象が。 多くの掲示板や書籍やMLに見られるオブジェクト指向問題なのかもしれませんね。 後、オブジェクト指向を説明する際に見られる比喩表現の話ですが、 これは、説明したい事柄Ａ（オブジェクト指向）に措ける関係構造を 多くの人が知っている事柄Ｂ（現実世界）に変換して 関係構造を説明しているのであって、 事柄Ａ自体を説明している訳では無いですよね。 つまり事柄Ａと事柄Ｂに措ける性質や問題を殺ぎ落として 比喩表現というのは成り立つ話である事を考えれば、 実は比喩表現で説明される事に然程の価値は無いのでは？と思います。 しかし比喩表現というのは、受け手にイメージを起こし易く、 解ったと勘違いさせるにはうってつけの手法です。 もし、本当に自分が伝えたい事がある場合は、 比喩表現だけで説明した気に成らない様に気をつける必要があり。 自分が説明を受ける時にに比喩表現が出てきた場合は、要注意って事なんでしょうね。 | ||||
|
投稿日時: 2005-02-22 21:03
脱線ですが、
違うと思う。 比喩は説明のための道具としてとても有益。 説明したい事柄が「関係構造」だと前提すれば、「説明したい事柄Ａ（オブジェクト指向）に措ける関係構造を多くの人が知っている事柄Ｂ（現実世界）に変換して関係構造を説明している」ことに問題はない。 もちろん、話者が説明したい事柄がその「関係構造」でないならその点においてマッピングがなされる比喩を用いることは誤解を招くだろう。 しかし関係構造の比喩を使ってオブジェクト指向を説明する場合というのは、関係構造を説明する場面ではないのか？ かたや、もし事柄Aの性質が説明したい対象ならば、Aの性質についての比喩を用いればよい。 要は、説明すべき対象を適切にとらえている比喩を用いていれば（その対象についての）理解は往々にして促進されるのであって、「比喩表現で説明される事に然程の価値は無い」とはまったく言えないと思われる。 「事柄Ａと事柄Ｂに措ける性質や問題を殺ぎ落として比喩表現というのは成り立つ」のはそこで比喩表現されているものが「事柄Ａと事柄Ｂに措ける性質や問題」でない場合（例えばそれらに無関係な関係構造）であって、比喩においてbaseとtargetとの間でマッピングされているものとされていないものを考える必要がある（厳密に区別できるとは限らないが）。 比喩の聞き手が、話し手が意図したマッピング以外についてまで対応関係が成り立つと類推してしまうのは誤解を生むもとだが、それは当のマッピングされた何かを比喩的に説明することの成果とは別の問題である。その恐れがある場合なら、こっちはこっちでフォローをすればよい（フォローがまた別の比喩であってもよいしね）。 「比喩表現が出てきた場合は、要注意」どころか、ありがたがって聞くほうがよいと思う。 ただし何についての比喩なのかを明確にしておくべし。 比喩表現は、それだけで説明した気になってもかまわない場合もあるし、そうならざるを得ない場合もある。 | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.