- - PR -
OOPがよくわかりません
| 投稿者 | 投稿内容 | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2002-12-10 09:20
初めまして。
私も「オブジェクト指向」とは、「モデリング」に尽きるのではないかと思います。 したがって「オブジェクト指向プログラミング」とは、「モデリング」によって 洗い出された情報(状態や振る舞い等)を表現する事ではないでしょうか？ 短くて簡単な意見ですが。 
| ||||||||||||||||||||||||||||||||
|
投稿日時: 2002-12-10 09:23
微妙にずれる意見かもしれませんが、jackさんは プログラム作成は今回が、はじめて
なのでしょうか、ある程度プログラム経験があると、プログラミングの世界観 というか アーキテキクチヤーが見えてきて、その上で oopというのを理解できると思うのですが、 | ||||||||||||||||||||||||||||||||
|
投稿日時: 2002-12-10 10:13
>私も「オブジェクト指向」とは、「モデリング」に尽きるのではないかと思います。
>したがって「オブジェクト指向プログラミング」とは、「モデリング」によって >洗い出された情報(状態や振る舞い等)を表現する事ではないでしょうか？ 用語の定義については断言できないのですが， とりあえず， A:モデリングレベルでのOOの利用 B：プログラミングレベルでのOOの利用 と分類した場合，リファクタリングやデザインパターンはBのレベルでは 非常に大きな意味を持ちますが，Aのレベルではほとんど無意味ですよね． また，一つのクラスにコードの大半が集中し，他のクラスにはほとんど コードがなくスカスカというのも，Bのレベルでは無視できない問題ですが， Aのレベルではほとんど無視されるのではないでしょうか． また，インターフェースの継承はA,Bの双方で重要ですが，実装の再利用としての 継承はAよりもBが中心でしょう． そういう意味での意識や考え方の違いはあると思います． ちなみに，OO言語は「OOが可能な言語」ではなく，「OOをサポートする 機能を持つ言語」と考えるべきだと思います．OOのモデリングを元に プログラムを作成するだけなら，Cだろうとアセンブラだろうと (理論上は)可能でしょうから．もちろん，「ここからはOO言語，ここからは 違う」という線引きが難しいのも事実です．よってVBの自称OO言語も， 嘘だとは断定できません． | ||||||||||||||||||||||||||||||||
|
投稿日時: 2002-12-10 10:23
YKIDさん
>それはともかく、多くの人が使う「クラスを分ける」って表現が気になります。 確かにクラスは分けませんね。「システムを分けて小さなクラスにする」というのが正しいのかな。 分けるのは、まだ十分に小さくなっていないシステムということ。 「属性（フィールド）」か「振る舞い（メソッド）」か、ということですが、私はメソッドこそ重要ではないかな、と思います。 クラスでは「カプセル化」と「抽象化」ということが言われます。 カプセル化というのは、皆さんの良く使うprivateってやつで、不正な値や矛盾した値が入らないようにする、つまりフィールドを外から触らせないこと。 抽象化というのは、例えば座標上の点を表すクラスがあるとしましょう。これはデカルト座標としても極座標としても値を得られるクラスだとします。 そのクラスを使う側からすれば、フィールドとしてデカルト座標で値を保持していようが極座標として保持していようが、両方を持っていて整合を取っていようが関係ないわけです。その値をfloatで保持していようがdoubleで保持していようが、二進化十進数で保持していようが、それも使う側では意識しなくて済みます。これが抽象化です。抽象的な「座標の点」のサービスを提供し、フィールドを外から意識させないことです。 それを考えれば、フィールドよりもメソッドの方が先になるというのは分かるのではないでしょうか。もちろん「このクラスはこの情報を責任持って保持する」というのは決まっているでしょうが、それをどのように持つかは振る舞い（メソッド）よりも先に決まることはありません。 get_XXX() set_XXX()も、まずそのメソッドが決まり、そしてフィールドが決まるべきです。 ・・・・理想は。 [ メッセージ編集済み 編集者: 一郎 編集日時 2002-12-10 10:25 ] | ||||||||||||||||||||||||||||||||
|
投稿日時: 2002-12-10 12:28
おもいもかけず議論が活発になってしまっている。。
まずソースコードが2000行になる事は設計の範疇ではなく実装の範疇です。 よって分析設計の段階ではそれは考慮しません。 しかし、コードが2000行とか3000行とかの巨大な物になってしまうという事は仕様にもよりますがクラス分析に失敗している可能性が高いです。 つまりそもそも分析設計が正常におこなわれていればそういうクラスが発生する事はありえません。
そうですね。クラス分析は仕様により変化するので巨大なクラスがあっても問題ない場合もあります。しかし、それは問題領域の分析が不十分であった可能性も捨てきれません。 おそらく分析がうまくいけば全てのクラスがシンプルな構造になるはずなのですが、、 # ぼくも結構失敗するので、エラそうには言えませんが、、
えーーと、とりあえず言葉の定義は明確にしないと議論にならないですし、正確なオブジェクト指向の理解をしているとは言えません。 それはまるで、交通ルールをしらないで、公道に出てるのとおなじです。 たしかに、経験により運転は可能かもしれませんが、経験中に交通事故を起す可能性が大です。
まずデザインパターンは分析設計の分野です。決して実装の部分の概念ではありません。 リファクタリングは実装の部分である事は異論ないです。 コード内容は分析設計では考慮しないものです。 それは実装者が考慮する物ですからね。
継承した方がいいかは分析設計の段階で決定されるべき物で実装者が決定する物ではありあません。 継承は特殊な型の関係の一種であり、関係の分析は分析設計者の仕事です。 実装者はそのあたりは考慮する物ではありません。 インターフェースに関しても分析設計者が考慮するもので実装者が考慮する物ではありません。 これはデザインパターンなどを参考にして、分析に、問題領域の適切な切りわけによりインターフェースを決定するにすぎません。
そうですね。システムというか問題領域の切りわけ、という感じになのでしょう。
このあたりはオブジェクト指向の基本というか、理論そのものになってしまう。 そういう機能を可能にしたプログラミング言語をオブジェクト指向言語というので。 なんか、卵が先か鶏が先かの話みたいになっている感じです。
....理想は、、ですね。実際の所失敗は結構しますので 
# しかし意外とオブジェクト指向という単語をしっていても # その理論的背景を知っている人って少ないのでしょうか、、 | ||||||||||||||||||||||||||||||||
|
投稿日時: 2002-12-10 13:17
＃もとの質問者の方へ．
＃このように，設計というものはいろいろと混乱するものなのです． >まずデザインパターンは分析設計の分野です。決して実装の部分の概念ではありません。 これは同感．ただし，実装に密接に関係したものです． 設計というのは，本質的に実装と関係したものですから． モデル化でさえそう．良いモデルを作成する際には実装まで考えて モデル化します．それはJavaVM仕様書を見ればよく分かります． >つまりそもそも分析設計が正常におこなわれていればそういうクラスが >発生する事はありえません。 また，これなどは原因と結果が逆な気がする． 「そういう肥大化したクラスが発生する設計は悪い設計である」 「そういうクラスが発生しないように設計する」 だけであって， 「正しい設計をすれば，そういうクラスが発生しない」 というものじゃない． ＃まあ，人によっては，「正しい設計をしたのだから，(どれだけ肥大化しても) ＃ただしいクラスなんだ！」という立場もありうるのかもしれませんが． ＃＃特に＠ITはUML，RUPよりのページなだけに，そういう立場の人が ＃＃多いのかも．デザインパターン，リファクタリング，Javaの世界で， ＃＃Effective Javaをお勧めするような人からすると，なんだかねー．．． >コード内容は分析設計では考慮しないものです。 >それは実装者が考慮する物ですからね。 こういう風に実装から乖離した設計は，意外に役に立たないもんです． ># しかし意外とオブジェクト指向という単語をしっていても ># その理論的背景を知っている人って少ないのでしょうか、、 理論的背景を知ってても，実際に役立たなければ意味がない． 結局は工学と理学の違いのようなもんじゃないですか． ＃別に理学を軽視しているわけじゃないので念のため． | ||||||||||||||||||||||||||||||||
|
投稿日時: 2002-12-10 13:49
こんばんわ、YKIDです。
＃OOPの話からはだいぶと外れた内容になってます。
私は、ここにソフトウェア開発の齟齬を生み出す原因の一部があると考えています。 ほげ刑事さんは、『クラスを「分け」たい』が『変えた視点で見えるオブジェクトに再配置（再構成）することがクラスを分けること』を同義だと認識してらっしゃるようなのですが、私が『クラスを「分け」たい』と言う言葉を単体で聞いたときに、『クラスを再配置（再構成）したい』という意図や意味を読み取れません。 日本語で『分ける』と『再配置/再構成』が同義ということは、聞いたことがありませんし、事実、それを知っているほげ刑事さんは、
と補足説明をしているのですよね。 で、このスレッドの冒頭でjackさんは
と、『クラスを分けたほうが...』とおっしゃっています。『クラスを分ける』ことを主体（主目的）においていて、『クラスを分ける』が『クラスを再配置/再構成したい』という意図を、文脈からも読み取りがたいといえます。 熟練者の多くは『クラスを分ける』という言葉を聞いたときに、『クラスを再配置/再構成したい』もしくは『システムの再分析を要する』とか言う意図に取れるのかもしれませんが、私が出会った多くの人は、『クラスを分ける』という言葉を使ったときに、本当にクラスを分解することに執心している現場を少なからず見受けられました。 jackさんがそうだということではなく、あくまでも私が見てきた初心者のことです。 システム全体で、クラスが3つ、うち1つが2000行というシステムであれば、2000行のクラスを分解することが、結果として『再配置/再構成した』ことと同じになるかもしれませんが、どのようなシステムであっても考え方として、 『2000行のクラスがある -> クラス設計/分析がおかしいと考える -> システムを再分析する -> 再構成する。』 という手続きを踏まなければならないと思っています。『クラスを分ける』と単純に表すことは簡単ですが、それを『再配置/再構成する』を捕らえるのは難しいです。（特に初心者の場合） で、私は、そうした用語の意味をあいまいなまま使ったり、そうしたあいまいな定義の用語を用いて説明するのは、齟齬を生みやすくするではないかと思うのです。 こうしたコミュニティでも、通常の仕事の上でも、熟練者は初心者に対して、齟齬を無くすような努力を行わなければならないと思います。 ＃少なくとも初心者が使う『クラスを分ける』という表現は、注意を促すべきだと考えていま ＃す。 | ||||||||||||||||||||||||||||||||
|
投稿日時: 2002-12-10 15:09
極端な話であっても，好ましくない表現ですので突っ込みます。 すべてのフィールドを public にすることは危険です。 外側のクラスから参照した場合，ほとんどのプログラマはstatic finalなものと思うのではないでしょうか。 絶対に自分だけしか使わないのであれば良いですが(良くないけど) そのクラスを使って何か作れ！といわれると，品質が信用できないです。 | ||||||||||||||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。