- - PR -
なぜオブジェクト指向を使うのか？
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-01-27 08:42
まりりさんへ
なるほど、英語の翻訳的に「指向」なのですね。了解！ Keisuke 判りやすい一例として取り上げた内容なのでご容赦を。（例が全てではありません） まぁこの辺でロートルは引っ込みます。 | ||||||||
|
投稿日時: 2004-01-27 10:19
「オブジェクト思考」という言葉がないわけではないです。ただしそれはPeter Coadの造語、 Object Thinkの訳語です。Object Thinkというのは、オブジェクトを擬人化して考えること、 自分がオブジェクトの立場になって考えてみること、知識を持つオブジェクトにその知識が 必要な振る舞いを持たせること、です。 「現実」をそのままプログラムに模写しようとすると、往々にしてデータと機能を分けて 考えがちです。現実の世界ではデータは振る舞いを持ちませんから。それを避けるためには、 プログラムの世界では「現実」とは異なり、データ(エンティティ)を能動的なオブジェクトと して考える必要があります。 | ||||||||
|
投稿日時: 2004-01-27 12:01
はにまるです。
悪夢を統べるものさんが今、一番言われている事は、 上記内容では、無いですか？ はにまる的思考で申しますと、 ------------------------------------------------------------------------------ 「オブジェクト指向」に対し”使う”の動詞はおかしい。 ”使う”のは、「オブジェクト指向」を技術体系化した、 「オブジェクト指向言語」であり、「ＵＭＬ」（こりゃ、違うかな？）で 「オブジェクト指向」に対して適切な動詞は”考える”。 ------------------------------------------------------------------------------ さらに話をすると ”「オブジェクト指向」で考えるメリット”は．．．と問い掛けられたら 返答者として非常に辛いですよね．．．？ なので、るるるさんは、”なぜオブジェクト指向使うのか？”のタイトルに されたと思います。 この矛盾を一越えするには、 １．オブジェクト指向で考えた、アーキテクチャや開発理論 ２．オブジェクト指向で考えた、設計理論 の議論が出来てやっと、 「オブジェクト指向」を使うメリットを述べれると思いますが、そこまで至っていない為、 「オブジェクト指向の技術体系」を使うメリットは？になる思います。 その様な意味で、 既に上がっている、実業務で直感的に感じるメリットが 今の所の当スレッドの答えでは無いでしょうか？ # 悪夢を統べるものさん 違っていたら 突っ込み御願い致します。 | ||||||||
|
投稿日時: 2004-01-27 12:05
Nishizaka さんが挙げられた点は、現在OOPLを使う理由の大きなものですね。
引っ込むなんておっしゃらず！次の発言期待してます。 | ||||||||
|
投稿日時: 2004-01-27 12:39
objectです。
「クラスは所与の前提たる存在」と拘っているのは、skulkerさん自身ではないでしょうか？ 前のレスには書きませんでしたが、 「Object-Oriented」という表現の裏には、 「Simula」の作成者の、我々の「クラス」が全てじゃないよ、大切なのは「対象（Object）」だよ！ という表明がある様に、私は感じています。 私は、「Class」に対しては2つの視点から考える必要があると思っています。 1）Object（対象）を類別（Classify）するという方法論の一つを示す 2）類別（Classify）の実装としての「Class」 #「Classify」には分類という言葉も使われている様ですが、類別（数学的概念）の方が明確になると私は思います。 「Self」（プロトタイプベース）に関しては、私は情報を殆ど持っていませんが、 私が認識している限りでは、「クラスの存在意義」が問われているとは思っていません。 実装上の、つまり2）の問題に対する指摘は、「C#」が出るまでは、確かに事実の様ですが…。 でも、「Class」に於ける実装上の多様性は、「C++」と「C#」のクラス実装の違いを見ても明らかだと思います。 C#では、全ての「型」が「Object」から派生してますし、属性・メタデータ・アセンブリ等を考えると、 ひょっとすると「Self」に優る部分もあるのではないでしょうか？ 現在のクラスは、考えられる手段の一つに過ぎないですが、 過去の考え方としてのソフトウエア資産をベースとした、確固とした一つの手段だと私は思います。 #実際、現在のクラスに何か不都合が出ても、何らかの方法で対処出来ると私は思っています。
型の概念とクラスの概念とありますが、 クラスは型の一つである と考えれば良いのではないでしょうか？ 私は「強く型付けされたクラスベースのOOPL」がそんなに悪くは無いと私は実感しています。 [ メッセージ編集済み 編集者: object 編集日時 2004-01-27 13:13 ] | ||||||||
|
投稿日時: 2004-01-27 12:41
objectです。
>unibonさん >そのモデルはすなわち科学法則から成り立ちます。 「科学法則」という表現がどこまでを意味をしているのか、明確では無いですが、 私は、科学法則だけでは無いと思います。 >ソフトウェアにはそのモデルが最初はありません。 確かに、最初からモデルが存在する保証はありません。 でも、モデルが無い所に、モデルを作成するからこそ、 「ビジネス・リエンジニアリング」にも繋がるのではないでしょうか？ >設計者が創造者になって作り込む必要があります。 概略としては、実際に行われている全てのユースケースを記述し、それに対してモデルを分析・設計し、実装すれば良いのではないでしょうか？ >科学法則のような単純さとは程遠い、矛盾だらけの泥臭い要求仕様から作り込まなければなりません。 >要求仕様は入出力(と処理内容)で規定されることが多く、いわゆる IPO(Input-Process-Output)ベース >ですが、これを制約条件としてそこからモデルを作るのは骨が折れます。科学者が実験結果から科学法 >則を発見するようなものです。 「入出力」が明確に決まっている場合は、それを明確に記述すべきだと思います。 しかし、要求仕様は、ユースケースと用語辞書で構成すべきだと私は思います。 要求仕様は、実際の対象に対して、 出来るだけ、重複が無い状態で、全ての場合（ケース）を尽くし、 尚且つ、そこでの不明な言葉（概念）が無い 状態にすれば良いのではないでしょうか？ もちろん、骨が折れる場合もあると思います。 「ビジネス・リエンジニアリング」になってる場合は、特に大変だと思います。 確かに、科学法則を発見する過程は、「創造」の過程ですから、大変だと思います。 でも、「ユースケース」を前提にすれば、それは「変換」の過程ですから、どちらかと言うと単純化されるのではないでしょうか？ >そこまで苦労するよりは、オブジェクト指向にあまりこだわらずに IPO のままで作り上げたほうが良い場合 >もあると思います。逆に言えば、要求仕様が素直ならばオブジェクト指向の利点が活きてくると言えます。 苦労するかどうかは、それを見る範囲・期間によって異なってきますよね。 その素直な要求仕様を作成するのが、「ユースケース」だと思います。 [ メッセージ編集済み 編集者: object 編集日時 2004-01-27 13:01 ] | ||||||||
|
投稿日時: 2004-01-27 13:09
るぱんです。
前置き。：今回も個人的な主観です。 クラスはたとえて言うならば人のように思える → 擬人化して考えよう 拡散した議論を収束させようとしている過程なのでは？ オブジェクト指向だから〜とかじゃなくて、 こう考えるとオブジェクト指向と言えるのではないだろうか？ の検証段階かと。 さて、本題。 本題の何故オブジェクト指向を使うのか？とはまた別次元に思います。 詳細各部ではなく、「オブジェクト思考とは何か？」「本来どういうものなのか？」 があって、その後で、「この場合は・・・」になるのかと。 概要でばらつきがある以上、詳細は混沌とすると考えます。 （各人で、前提条件が違うでしょうし。） | ||||||||
|
投稿日時: 2004-01-27 13:34
はにまるです。
るぱんさんの補足です。
確かに一番最初のメッセージが、こう締め括られています。 ”問いかけから始めてみてはどうでしょう？” ここに”るるるさん”のシタタカさ（良い意味で！）を感じます。 つまり、オブジェクトを議論するスレッドは、これから立つけど まず”ここから話してみては”と言う、公益を考慮した発言です。 折角の”高度な議論”も、”基本的な議論”とごっちゃになると 色褪せて勿体無いと思います。 勉強会的議論での会議室の立ち振る舞いは、 皆様全員が成れている訳では無いと考えていますので、難しいとは思いますが、 タイミングを見計らって別途スレッドを立ち上げては如何でしょうか？ # って自分もか！ # しかも、スレッドの趣旨を履き違えていたのを今、気が付いたし．． 反省＞＜ | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。