@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- @IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
オブジェクト指向の嬉しさについて
投稿者 | 投稿内容 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-06-16 16:31
債務 != 借金 ですし、オブジェクト間の契約によって各オブジェクトがすべき仕事の内容が決定されるという「契約による設計 (Design by Contract)」に基づいて用語の整合性を取るなら、法律学的には「債務」が正しいですね。
ただ英語では obligation ではなく responsibility と表記されるので、訳語としては「責務」でよいと思います。 | ||||||||||||
|
投稿日時: 2004-06-16 16:40
この場合 適切な粒度と部品化するように意識して作成する必要はありますけどね、でないと使えない。さらにある程度独立性があり それ自体で完結しているようにも作れればより望ましいですが... | ||||||||||||
|
投稿日時: 2004-06-16 16:51
るぱんです。 「法律学的に」で引っかかっているのですが、 どのへんが「法律学的に」・・・? 債務は責務を切り分けて譲り渡す方の義務では・・・? 分割された側のオブジェクトが負う物は「責務」になるんじゃないかと・・・? どうしても、「債務」と言う言葉の使い方に非常に違和感を感じるのです。 宜しくお願いします。 | ||||||||||||
|
投稿日時: 2004-06-16 17:12
んー。
今更、責務と債務で論争が起きるなんて思ってませんでしたねぇ。 ってのは、おいといて・・・ 最近、オブジェクト指向開発で嬉しかったのは、製造に限定した話で申し訳ないのですが、プログラマの制御がし易かった点でしょうかね。 開発するシステムのフレームワーク部分を先に構築しておいて、プログラマの人達には、必ずフレームワークで定義されている抽象クラスを継承して、コーディングするようにさせていたので、オブジェクト指向に不慣れな人に組んでもらっても、枠組みの部分が出来ているのでソースコードが壊滅的になるという事が防げたことが嬉しかったですね。 あとは、不慣れな人が少ない負担で、オブジェクト指向に触れる事が出来、その利点に納得することができたことも良かったと思います。 [ メッセージ編集済み 編集者: NAL-6295 編集日時 2004-06-16 17:22 ] | ||||||||||||
|
投稿日時: 2004-06-16 17:44
Takiroです.要らぬ物議を醸してしまい申し訳ありません.
先日のラウンドテーブルの記事でファウラーさんが『コード!』と唱えているのが念仏のように聞こえてきました.抽象概念を共有するというのはさしも難しいことなのでしょうね.
ご意見ありがとうございます. この辺りのノウハウは経験を積むことでしか得られないのでしょうかね?
私も組み込みの世界に属してまして,まさにオブジェクト指向の試練をくぐらなければならない状況です.廻りも『不慣れな人』だらけで前途多難な状況でして... 構造化設計自体も経験ない中で無謀なことしてますので,少しこの辺りを押さえたいと考え質問させていただきました. その中でこのような実践的な例は大いに参考になります. 情報提供ありがとうございました. [ メッセージ編集済み 編集者: Takiro 編集日時 2004-06-16 17:48 ] | ||||||||||||
|
投稿日時: 2004-06-16 18:23
え! 組込みの世界は、、全く解らんです。 私は業務系なので、機能仕様変更に対する影響度はレベルが全然違うと思います。 環境説明すべきでした。失礼致しました。m(_ _)m では返答内容を削って投稿致します。(使えない情報とは思いますが)
私の意図は仰る通りです。きっと認識は合っていると思います。
構造化プログラミングで部品化を阻害する重大原因として、関数間での「情報」の受渡が 1.単一データになってしまう事(1情報に複数の値を持たす事が出来ない) 2.特定の型になってしまう事 です。 1番は、情報の遣り取りを(動的)配列や構造体を利用する事である程度緩和出来ますが、 構造体についてはデータ構成が事前に解っている事が前提となります。 2番は、異なる型によるオーバーロードで解決出来ますが複数項目は適しません。 つまり 処理Aが「結果を返す時」、またその結果を処理Bが情報を「受取る時」に 共に個別プログラムで定めた「特定の型で定義された変数」で操作する必要があり、 部品化の阻害になる事が多々の局面で遭遇します。 逆を反せば、値と型が変動的に保管出来且つ、内容判断出来る形式で情報連携できれば 良い訳で、この際にオブジェクトが威力を発揮出来る訳です。 CSV出力の例題を削ったから、具体的じゃ無いですが勘弁してくらはい。 | ||||||||||||
|
投稿日時: 2004-06-16 19:59
要は民法(債権法)の話なのですが。 債権というのは、誰かが誰かに何かをすることを要求できる権利、 債務というのは、誰かが誰かに何かをしなければならない義務です。 「責務」という単語は契約法の用語として出てくる事はありません。あくまで「債務」です。 「隣人に夜9時以降にピアノを弾くなという権利」「従業員に会社のために働けという権利」「A商店が買い物の代金として100万円要求できる権利」「A商店に代金と引き換えに商品の引き渡しを要求できる権利」全て債権です。 「夜9時以降にピアノを弾いてはならないという義務」「従業員が会社のために働く義務」「A商店に買い物の代金として100万円支払う義務」「A商店が代金と引き換えに商品を引き渡さなければならないという義務」全て債務です。 債権・債務というのは大抵は契約によって生じます。雇傭契約、売買契約、贈与契約、請負契約、いろいろです。 バートランド・メイヤーは、「処理の呼び出し元が事前条件を守る事を条件として、処理の呼び出し先がサービスを提供する(処理の呼び出し後に事後条件が満たされる事を保証する)」という取り決めをオブジェクト同士で行い、互いの役割分担を決定するという設計を「契約による設計 Design by Contract」 と表現しています。 この契約によって、 呼び出し元は「自分が事前条件を満たす」という義務と「相手に事後条件の充足を要求できる」という権利を持ち、 呼び出し先は「自分が事後条件を満たす」という義務と「相手に事前条件の充足を要求できる」という権利を持つ訳です。 これらの関係は、契約から生じた「誰かに何かを要求できる権利」「誰かに何かをしなければならない義務」であり、法律学上、明らかに「債権」「債務」であると解釈できます。 というだけの事です。 でもresponsibilityの訳語としては責務の方が適切な気がします。世間一般では債権・債務というと借金を連想される人の方が多いようですし。 | ||||||||||||
|
投稿日時: 2004-06-16 20:53
これが、重大原因だとは特に思えないのですが。どうなんでしょう? 個人的には、振る舞いとデータが分離していることが、最大要因だと思うのですが... |