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

投稿者

投稿内容

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

投稿日時: 2004-06-16 16:31

債務 != 借金ですし、オブジェクト間の契約によって各オブジェクトがすべき仕事の内容が決定されるという「契約による設計 (Design by Contract)」に基づいて用語の整合性を取るなら、法律学的には「債務」が正しいですね。

ただ英語では obligation ではなく responsibility と表記されるので、訳語としては「責務」でよいと思います。

七味唐辛子: ぬし; 会議室デビュー日: 2001/12/25; 投稿数: 660

投稿日時: 2004-06-16 16:40

引用:

Takiroさんの書き込み (2004-06-16 14:26) より:

その前提で，
部品を作ってゆき成果物をなるべく部品またはその組み合わせを多用して構築する姿勢が，オブジェクト指向を利用すると構造化よりも実現しやすいということと解釈しましたが，間違いないでしょうか？
その意味で，私の投げた問いかけである『機能変更』への強さが，"部品の使いまわしにより"実現されるということですね．

この場合　適切な粒度と部品化するように意識して作成する必要はありますけどね、でないと使えない。さらにある程度独立性があり　それ自体で完結しているようにも作れればより望ましいですが...

るぱん: ぬし; 会議室デビュー日: 2003/08/01; 投稿数: 1370

投稿日時: 2004-06-16 16:51

引用:

skulkerさんの書き込み (2004-06-16 16:31) より:
債務 != 借金ですし、オブジェクト間の契約によって各オブジェクトがすべき仕事の内容が決定されるという「契約による設計 (Design by Contract)」に基づいて用語の整合性を取るなら、法律学的には「債務」が正しいですね。

ただ英語では obligation ではなく responsibility と表記されるので、訳語としては「責務」でよいと思います。

るぱんです。

「法律学的に」で引っかかっているのですが、
どのへんが「法律学的に」・・・？

債務は責務を切り分けて譲り渡す方の義務では・・・？
分割された側のオブジェクトが負う物は「責務」になるんじゃないかと・・・？

どうしても、「債務」と言う言葉の使い方に非常に違和感を感じるのです。
宜しくお願いします。

NAL-6295: ぬし; 会議室デビュー日: 2003/01/26; 投稿数: 966; お住まい・勤務地: 東京

投稿日時: 2004-06-16 17:12

んー。
今更、責務と債務で論争が起きるなんて思ってませんでしたねぇ。

ってのは、おいといて・・・
最近、オブジェクト指向開発で嬉しかったのは、製造に限定した話で申し訳ないのですが、プログラマの制御がし易かった点でしょうかね。
開発するシステムのフレームワーク部分を先に構築しておいて、プログラマの人達には、必ずフレームワークで定義されている抽象クラスを継承して、コーディングするようにさせていたので、オブジェクト指向に不慣れな人に組んでもらっても、枠組みの部分が出来ているのでソースコードが壊滅的になるという事が防げたことが嬉しかったですね。
あとは、不慣れな人が少ない負担で、オブジェクト指向に触れる事が出来、その利点に納得することができたことも良かったと思います。

[ メッセージ編集済み編集者: NAL-6295 編集日時 2004-06-16 17:22 ]

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

投稿日時: 2004-06-16 17:44

Takiroです．要らぬ物議を醸してしまい申し訳ありません．

先日のラウンドテーブルの記事でファウラーさんが『コード！』と唱えているのが念仏のように聞こえてきました．抽象概念を共有するというのはさしも難しいことなのでしょうね．

引用:
七味唐辛子さんの書き込み (2004-06-16 16:40) より: この場合　適切な粒度と部品化するように意識して作成する必要はありますけどね、でないと使えない。

ご意見ありがとうございます．
この辺りのノウハウは経験を積むことでしか得られないのでしょうかね？

引用:
NAL-6295さんの書き込み (2004-06-16 17:12) より: オブジェクト指向に不慣れな人に組んでもらっても、枠組みの部分が出来ているのでソースコードが壊滅的になるという事が防げたことが嬉しかったですね。

私も組み込みの世界に属してまして，まさにオブジェクト指向の試練をくぐらなければならない状況です．廻りも『不慣れな人』だらけで前途多難な状況でして．．．
構造化設計自体も経験ない中で無謀なことしてますので，少しこの辺りを押さえたいと考え質問させていただきました．
その中でこのような実践的な例は大いに参考になります．
情報提供ありがとうございました．

[ メッセージ編集済み編集者: Takiro 編集日時 2004-06-16 17:48 ]

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

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

引用:
Takiroさんの書き込み (2004-06-16 17:44) より: 私も組み込みの世界に属してまして

え！

組込みの世界は、、全く解らんです。
私は業務系なので、機能仕様変更に対する影響度はレベルが全然違うと思います。
環境説明すべきでした。失礼致しました。m(_ _)m

では返答内容を削って投稿致します。（使えない情報とは思いますが）

引用:
Takiroさんの書き込み (2004-06-16 14:26) より: 『ユーザ要求』＝成果物，『システム要求』＝部品という解釈で間違いないでしょうか？その意味で，私の投げた問いかけである『機能変更』への強さが，"部品の使いまわしにより"実現されるということですね．

私の意図は仰る通りです。きっと認識は合っていると思います。

引用:
難しくなければ，何か具体的な例を紹介していただけると助かります．

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

１番は、情報の遣り取りを（動的）配列や構造体を利用する事である程度緩和出来ますが、
構造体についてはデータ構成が事前に解っている事が前提となります。

２番は、異なる型によるオーバーロードで解決出来ますが複数項目は適しません。

つまり
処理Ａが「結果を返す時」、またその結果を処理Ｂが情報を「受取る時」に
共に個別プログラムで定めた「特定の型で定義された変数」で操作する必要があり、
部品化の阻害になる事が多々の局面で遭遇します。

逆を反せば、値と型が変動的に保管出来且つ、内容判断出来る形式で情報連携できれば
良い訳で、この際にオブジェクトが威力を発揮出来る訳です。

ＣＳＶ出力の例題を削ったから、具体的じゃ無いですが勘弁してくらはい。

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

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

引用:

るぱんさんの書き込み (2004-06-16 16:51) より:
引用:

skulkerさんの書き込み (2004-06-16 16:31) より:
債務 != 借金ですし、オブジェクト間の契約によって各オブジェクトがすべき仕事の内容が決定されるという「契約による設計 (Design by Contract)」に基づいて用語の整合性を取るなら、法律学的には「債務」が正しいですね。

ただ英語では obligation ではなく responsibility と表記されるので、訳語としては「責務」でよいと思います。

るぱんです。

「法律学的に」で引っかかっているのですが、
どのへんが「法律学的に」・・・？

債務は責務を切り分けて譲り渡す方の義務では・・・？
分割された側のオブジェクトが負う物は「責務」になるんじゃないかと・・・？

どうしても、「債務」と言う言葉の使い方に非常に違和感を感じるのです。
宜しくお願いします。

要は民法(債権法)の話なのですが。

債権というのは、誰かが誰かに何かをすることを要求できる権利、
債務というのは、誰かが誰かに何かをしなければならない義務です。

「責務」という単語は契約法の用語として出てくる事はありません。あくまで「債務」です。

「隣人に夜9時以降にピアノを弾くなという権利」「従業員に会社のために働けという権利」「A商店が買い物の代金として100万円要求できる権利」「A商店に代金と引き換えに商品の引き渡しを要求できる権利」全て債権です。

「夜9時以降にピアノを弾いてはならないという義務」「従業員が会社のために働く義務」「A商店に買い物の代金として100万円支払う義務」「A商店が代金と引き換えに商品を引き渡さなければならないという義務」全て債務です。

債権・債務というのは大抵は契約によって生じます。雇傭契約、売買契約、贈与契約、請負契約、いろいろです。

バートランド・メイヤーは、「処理の呼び出し元が事前条件を守る事を条件として、処理の呼び出し先がサービスを提供する(処理の呼び出し後に事後条件が満たされる事を保証する)」という取り決めをオブジェクト同士で行い、互いの役割分担を決定するという設計を「契約による設計 Design by Contract」と表現しています。

この契約によって、
呼び出し元は「自分が事前条件を満たす」という義務と「相手に事後条件の充足を要求できる」という権利を持ち、
呼び出し先は「自分が事後条件を満たす」という義務と「相手に事前条件の充足を要求できる」という権利を持つ訳です。

これらの関係は、契約から生じた「誰かに何かを要求できる権利」「誰かに何かをしなければならない義務」であり、法律学上、明らかに「債権」「債務」であると解釈できます。

というだけの事です。

でもresponsibilityの訳語としては責務の方が適切な気がします。世間一般では債権・債務というと借金を連想される人の方が多いようですし。

七味唐辛子: ぬし; 会議室デビュー日: 2001/12/25; 投稿数: 660

投稿日時: 2004-06-16 20:53

引用:
はにまるさんの書き込み (2004-06-16 18:23) より: 構造化プログラミングで部品化を阻害する重大原因として、関数間での「情報」の受渡が１．単一データになってしまう事（１情報に複数の値を持たす事が出来ない）２．特定の型になってしまう事です。

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

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

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

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