オブジェクト指向の嬉しさについて

投稿者

投稿内容

skulker: ベテラン; 会議室デビュー日: 2004/06/08; 投稿数: 67

投稿日時: 2004-06-16 23:54

引用:

七味唐辛子さんの書き込み (2004-06-16 20:53) より:
引用:

はにまるさんの書き込み (2004-06-16 18:23) より:

構造化プログラミングで部品化を阻害する重大原因として、関数間での「情報」の受渡が
１．単一データになってしまう事（１情報に複数の値を持たす事が出来ない）
２．特定の型になってしまう事
です。

これが、重大原因だとは特に思えないのですが。どうなんでしょう？
個人的には、振る舞いとデータが分離していることが、最大要因だと思うのですが...

そうですね、これらは構造化プログラミングとは無関係ですよね。パラダイムの問題ではなく、各言語の仕様の問題ではありませんか?

LISPみたいに複数の値を返せる多値の関数を作れる言語もありますし。

型の問題は構造化プログラミングだろうとオブジェクト指向だろうと、型付けのある言語だとみんな該当する可能性があります。Javaの型システムも不自由だと批判される事がありますし (例えば、Eiffel はサブクラスでルーチンをオーバーライドする時に仮引数や戻り値の型を変更できたりする)。

やっぱり構造化プログラミングの問題は、手続とデータ構造が分かれていて、変更時に保守する部分がどうしても複数箇所になってしまう事でしょう。

はにまる: ぬし; 会議室デビュー日: 2003/12/19; 投稿数: 969; お住まい・勤務地: 誤字脱字の国

投稿日時: 2004-06-17 09:24

引用:

七味唐辛子さんの書き込み (2004-06-16 20:53) より:
引用:

はにまるさんの書き込み (2004-06-16 18:23) より:

構造化プログラミングで部品化を阻害する重大原因として、関数間での「情報」の受渡が
１．単一データになってしまう事（１情報に複数の値を持たす事が出来ない）
２．特定の型になってしまう事
です。

これが、重大原因だとは特に思えないのですが。どうなんでしょう？

引用:
skulkerさんの書き込み (2004-06-16 23:54) より: そうですね、これらは構造化プログラミングとは無関係ですよね。各言語の仕様の問題ではありませんか?

あう。

仰る通りですね。データの保持手段（型、構造、階層化等）は「構造化」か「オブジェクト指向」か
は、直接関係ありませんでした。早とちりですね。申し訳ございません。 m(_ _)m

そして、ご指摘ありがとうございます。整理が出来ました。

[ メッセージ編集済み編集者: はにまる編集日時 2004-06-17 09:28 ]

Takiro: 会議室デビュー日: 2003/06/06; 投稿数: 9; お住まい・勤務地: 愛知県

投稿日時: 2004-06-18 13:29

Takiroです．色々なご意見ありがとうございます．

ここまでの意見を私なりに整理してみました．

当初の問いかけ『構造化とオブジェクト指向で，機能変更時の影響にどんな違いが出るのか』に対し，

①機能変更自体は同じように影響を受ける
②オブジェクト指向では『機能間の連携』部分で関係を上手く整理できる
　　（整理しやすい環境を提供してくれる，というのが正しい解釈でしょうか）

つまり有意差は，機能間で連携しなければならない(機能分割ツリーでは抜け落ちてしまう)部分において，

構造化では，

何ら指針が無いため冗長な関係や強い結びつきが出てしまい，上手く設計していれば必要なかった変更やチェックまで行わなければならなくなる可能性がある(制御は可能だが困難)．

オブジェクト指向を使えば，

オブジェクトの中に，ある観点から関係すると思われる機能とデータをまとめ，外部との関係を薄くすることが可能となる．
言い換えると，機能間の関係を積極的にコントロールすることが可能である．

すいません，誤解が生まれないよう局所化とか関連とかオブジェクト指向に直結する言語使うのあえて避けてみました．
また，色々なご意見を整理した結果として，個別の引用を省略してしまいますが，ご理解願います．

これまでのところの解釈として，おかしな部分がありましたらご指摘ください．

追伸：これは本題とは関係ないのですが，例の『責務』と『債務』絡みで少し確認したい部分があります．この場では『責務』が最適という認識で良いものとして，

私自身，質問にも書きましたように『責務』という言葉で表そうとしている概念を，オブジェクトが外部に提供する個々の『機能』であると考えておりました．

tak3さんの『機能の変更による責務の変更は発生しません』ですとか，skulkerさんのresponsibilityという使われ方をみていると，私自身『機能』と『責務』の関係がよくわかっていないかもしれないと認識した次第です．

さらに派生してしまい申し訳ありませんが，こちらもご教授戴けると幸いです．

tak3: ベテラン; 会議室デビュー日: 2004/04/15; 投稿数: 80; お住まい・勤務地: 菜の花・銀杏

投稿日時: 2004-06-18 23:09

例え話をしますと・・・

プロマネとプログラマがいたとします。
Ａプロジェクトが終わったあと、Ｂプロジェクトでも同様のチーム構成になりました。
# 非常に小さいチームですね

責務というか役割でいうと
プロマネ：プログラマに仕事をさせる
プログラマ：プログラムを作る

となります。
この関係は、ＡプロジェクトでもＢプロジェクトでも変わりありません。

作成するプログラムはプロジェクトで違うわけですから、
プログラム作成という機能が変更されたと考えられます。
Ａプロジェクト用のプログラム作成（機能）
Ｂプロジェクト用のプログラム作成（機能）
これ（機能変更）は、責務などに関係なくどうしても避けられないものです。
これを、どのように吸収というか他に影響させないかが重要になります。

カプセル化が上手くいっていない場合：
プロマネがプログラマに対して「Ａプロジェクト用のプログラム作って」と指示をしたために
Ｂプロジェクトでは「Ｂプロジェクト用のプログラム作って」という風に変更になってしまいました
（機能変更の影響は、プロマネとプログラマ）

カプセル化ができている場合：
プロマネは「プログラム作って」とだけお願いする場合は、
Ａプロジェクト、Ｂプロジェクトでもプログラマに対するお願いのしかたが同じになります。
（影響は、プログラマのプログラム作成機能のみ）

責務という話でいうと、プログラムの作り方をプロマネが指示しちゃダメということです。
それこそ、プログラマが別のプログラマに作ってとお願いしたとしても、プロマネにとっては
どうでもよいことです。
# 責務 = 役割と解釈しています。間違っていたらツッコミお願いします。

さて、もう少し抽象化とポリモーフィズムの話をつっこむと・・・
「プログラム作って」でなく「仕事しろ」インタフェースを作成することで、（抽象化）
プロマネは「仕事しろ」とだけ命令すれば、メッセージを受ける相手が、
デザイナになってもアルバイトになっても、
命令した相手にいろいろ仕事をさせることが可能です。
当然仕事の内容は命令した相手によって違います。（ポリモーフィズム）

プログラマ．仕事しろ
デザイナ．仕事しろ
アルバイト．仕事しろ

中途半端な例え話で逆にわかりにくいでしょうか？

Takiro: 会議室デビュー日: 2003/06/06; 投稿数: 9; お住まい・勤務地: 愛知県

投稿日時: 2004-06-19 16:18

Takiroです．ご説明ありがとうございます．

なるほど，責務というのが関数名に該当し，機能がその中身である．

という関係ですね．
tak3さんの『機能の変更による責務の変更は発生しません』の意味がよくわかった気がします．

『Ａ(Ｂ)プロジェクト用の』がプロマネとプログラマ間の強い結びつきになってしまう．関数名(メソッド名)自身が問題なのではないですが，構造化，正確には手続き型言語では同じ関数名で別の中身を引っ張ることが難しいので必然的に，強く結びついてしまう．

はにまるさんの，

構造化プログラミングで部品化を阻害する重大原因として・・・
２．特定の型になってしまう事

という指摘がこれに該当するということですね．

構造化(手続き型言語)では，関数名と中身が強く結びついているが故，必然的に呼び出し元と呼び出し先が強く結びついてしまう．

オブジェクト指向ではポリモーフィズムが容易にこの問題を解決してくれるので，似たような機能(メソッドの中身)を持つオブジェクトのメソッド名を同じにしておけば，異なるオブジェクト(Ａプログラム・Ｂプログラムとか，プログラマ・デザイナ・アルバイト)の持つ機能の違いを，呼び出すオブジェクトを替えるだけで実現できます．

ということですね．

引用:
tak3さんの書き込み (2004-06-18 23:09) より: 中途半端な例え話で逆にわかりにくいでしょうか？

いえいえ，すごく良くわかりました．
具体例は一側面しか見えないという弊害はあるのかもしれませんが，私のような勉強中の身には理解を助ける有効な手段ではないかと思います．

典型的な例を学び，『責務』のような抽象的な用語の持つ他の側面を，別の例や経験を通して徐々に理解していけばよいのではないですかね．

今回の例など，他の人に説明するときにも使えそうですね．

ありがとうございました．

skulker: ベテラン; 会議室デビュー日: 2004/06/08; 投稿数: 67

投稿日時: 2004-06-19 17:20

BoochとRumbaughの定義によれば、責務とは「型またはクラスの契約または義務」だそうです。
オブジェクトによって提供されるサービスだと私は理解しています。
例えば、xクラスはyクラスのオブジェクトを生成する責務を負う、とか、入力データの妥当性を検証する責務をzオブジェクトに割り当てる、とか。

上のたとえ話で言うなら、「プログラムの実装の詳細を決定する責務を、PMではなくプログラマに割り当てる事により、PMとプログラマを疎結合にして、実装が変更になった場合の影響をプログラマに局所化する」と言う事では。
カプセル化がまずくても(カプセル化できない言語であろうとも)、責務の割り当てがうまくできれば変更は局所化できます。

Claig Larmanの「実践UML」なんぞを読むと責務の割り当てについてイメージつかめると思います。

もうひとつ。オブジェクト指向と手続型を対比させるのに違和感があります。C++もJavaも思いっきり手続型ですよね。オブジェクト指向プログラミングも学術的には「手続によるデータ抽象」に分類されるようです。

[ メッセージ編集済み編集者: skulker 編集日時 2004-06-19 17:25 ]

Takiro: 会議室デビュー日: 2003/06/06; 投稿数: 9; お住まい・勤務地: 愛知県

投稿日時: 2004-06-19 22:08

Takiroです．

引用:
skulkerさんの書き込み (2004-06-19 17:20) より: 上のたとえ話で言うなら、「プログラムの実装の詳細を決定する責務を、PMではなくプログラマに割り当てる事により、PMとプログラマを疎結合にして、実装が変更になった場合の影響をプログラマに局所化する」と言う事では。

プログラマに『割り当てる』という辺りに，『責務』の責務たるゆえんがあるわけですね．
ただ，『PMではなく』という辺り，つまり，PMに『プログラムの実装の詳細を決定する責務』を割り当てるとどうなるのかがうまくイメージできません．
休みで少し頭がぼけているかもしれません．

引用:
Claig Larmanの「実践UML」なんぞを読むと責務の割り当てについてイメージつかめると思います。

ご紹介ありがとうございます．
Amazonで少し調べたのですが，647ページとすごいボリュームですね．

4 推敲フェーズの反復2(反復2とその要件
責任割り当てのためのGRASPパターンほか)

辺りを読めばよいのでしょうか？
それ以外にも色々『実践的』な開発プロセスが記載されていそうで興味深いです．

引用:
もうひとつ。オブジェクト指向と手続型を対比させるのに違和感があります。C++もJavaも思いっきり手続型ですよね。オブジェクト指向プログラミングも学術的には「手続によるデータ抽象」に分類されるようです。

私も書いていて『手続き型言語』という言葉には少し抵抗ありました．
どのプログラミング言語も構造化用とかオブジェクト指向用のためだけに作られたわけでもないし，特定の用途だけに専用化されたものから非常に汎用性を持っているものなど一概に括れるものではないことは認識しております．
誤解を招くような記述をして申し訳ありませんでした．

«前のページへ 1|2|3

オブジェクト指向の嬉しさについて

スキルアップ／キャリアアップ（JOB@IT）