＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
オブジェクト指向の嬉しさについて
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-06-15 12:19
はじめまして，takiroと申します．
前のスレッドにちょっと便乗する形でみなさんのご意見いただきたく投稿しました． 私もオブジェクト指向勉強中の身ですが，オブジェクト指向の嬉しさについて今ひとつ実感できない部分があり，よく理解できていないと悩んでおります． 嬉しさの一つに仕様変更への対応のしやすさみたいなものがあると思います． オブジェクト指向により狙いどおり局所化などで実装・テスト含め工数が大きく削減できるとするとすごく魅力のあります． しかしやってみると実際には．．．みたいな話もよく聞きます． 確かに構造化分析みたいな機能分割して行くパターンだと上位レベルの機能を変更しなければならなくなった場合に，その下にある機能を実装している部分は全て影響を受けかねないというのはイメージできます． オブジェクト指向では，ユースケース分析のところである程度機能分割してから各オブジェクトの責務として配分して行くイメージかなぁと考えております（既にこの時点で間違っているかも）． 仕様変更が機能の変更だとして，構造化とオブジェクト指向でもメソッド事態には同じように影響してしまうように思えてしまいます． 機能の切り出し ⇔ オブジェクトの切り出し ≒ 幾つかの機能をデータと一緒にまとめる 機能の上下関係には有意差は無い（ハズ？） ⇒ とすれば，オブジェクト指向でも同じだけ変更が発生する それとも機能単位自体が変わってくるものなのでしょうか？ この辺りまだよくイメージが沸かないもので．． ぜひ，皆さんの意見をお聞かせください． | ||||||||
|
投稿日時: 2004-06-16 09:49
私は、「オブジェクト指向言語」は仕様変更に対応し易いシステム構成が 構築出来る道具と考えています。 つまり冷たい言い方をすれば、構造化言語で仕様変更に強い構成を設計出来ない人が オブジェクト指向言語を用いても仕様変更に強い構成を設計が出来る訳が無いと 考えています。 後、仕様変更と言ってもピンキリですが機能変更レベルは確かに影響度は強いですね。 ただ、機能変更によりＯＳや言語が変る事は殆ど無いと思います。 つまり、ＯＳや言語が持つ仕様要求の範囲は、保証される訳です。 この範囲に守られた物が、共通部品、デザインパターン、フレームワーク等です。 仕様というと、ユーザの要求のみを考えますが、実際はシステム（言語やＯＳ）の仕様 から発生する要求も存在し、ＩＴ技術者は、「ユーザ要求」と「システム要求」が 一致する箇所を模索する仕事と考えています。 『ユーザ要求』→→→→ （接点） ←←←←『システム要求』 この際、「システム要求」から作り挙げた「構成」は「ユーザの要求」からの変更依頼に 強い性質を持ちます、「オブジェクト指向プログラミング」が変更に強いと言われる所以は、 「構造化プログラミング」に比べ、「システム要求」から作り込める範囲が広いからです。 概念図で表せば下記の通りです。 構造化 ：『ユーザ要求』→→→→→→ （接点） ←←『システム要求』 オブジェクト：『ユーザ要求』→→ （接点） ←←←←←←『システム要求』 ※「→」はユーザ要求からの影響を受けます。 ※「→」が減れば作業効率が高いと考えれます。 ※「構造化プログラミング」では「オブジェクト指向プログラミング」に比べ（接点）が 左に行ける限界点の発生が早いです。 つまり、「オブジェクト指向プログラミング」では「→」の数を減らし「←」の数が 「構造化プログラミング」よりも増やせる訳ですが、「オブジェクト指向言語」自体が 「←」の数を増やしてくれる訳ではありません。 # ただし、言語や開発環境が提供するクラスや各種ツールは「←」を増やしてくれる物です。 過去は「ハード構成」「ＯＳ」「言語」を規定し、ユーザ要求に制限を掛けていましたが、 オブジェクト指向の利点を生かすのであれば、「アーキテクチャ」や「フレームワーク」を 説明し、ユーザ要求に追加制限を掛ける事が大切と思います。 以上が、はにまる個人の考えです。 # 一部言葉の訂正 [ メッセージ編集済み 編集者: はにまる 編集日時 2004-06-16 11:32 ] [ メッセージ編集済み 編集者: はにまる 編集日時 2004-06-16 11:35 ] | ||||||||
|
投稿日時: 2004-06-16 12:41
オブジェクトの分割を機能でなく債務の分割をすれば"機能の変更による債務の変更は発生しません” Strutsフレームワークでいうとvalidateメソッド、resetメソッドが、良い例だと思います。 #下記の例はStrutsとは関係ありません 以下の処理があるとします。 ・データ整合性を判定して、画面遷移先を変更する ここでは、オブジェクトを２つ抽出しました。 １．データ ２．画面遷移コントローラ 機能としては４つ抽出します。 あ．データ保持 い．データの整合性判定 う．画面遷移先決定 え．画面を遷移させる 機能分担Ａ案 データ：データを保持するクラス（機能 あ） コントローラ：データの内容をチェックし、遷移先を決めて遷移させるクラス（機能 いうえ） というようにしました。 この場合、コントローラはデータの構造を知っている必要があり（データの内容をチェックするから） データの保持する内容、データ種類の増加により仕様変更、仕様追加が発生します。 機能分担Ｂ案 データ：データを保持する。データの内容をチェックする（機能 あい） コントローラ：データにチェック結果を聞く、遷移先を決めて遷移させるクラス（機能 うえ） この場合、コントローラはデータへチェック結果を聞くことができれば、 データの構造を知る必要はありません。 さて、こう考えると １．データを保持する。データの内容により遷移先を決定する ２．データに遷移先を聞く、遷移先へ遷移させる。 というような構成や 「データの遷移先は変更されやすいので外部ファイル化したいなぁ・・・」 とか、いろいろ出てくると思います。 機能自体は変更される可能性が高いですが、 その機能を誰が行なうのか？などを適切に設計できれば、仕様変更、追加は 局所化されるので怖くないです。 #そのように設計したいものです・・・日々精進ですね。
同感です。 実際にＡ案でつくられたコード（Java）に遭遇しました。 instanceof でデータ種別を判断して云々という それを見て、マネをしだす新人様・・・ マネというより仕様追加なのですが、新人にコードをリファクタリングできるわけもなく、 めでたく（？）if分岐が追加されました。 新人のレベルでは止むを得ない対応だと思いますし、コード（if文）にバグがあったわけでもありません。 # でも、膨大なif文の数に疑問ぐらいは持ってもいいんじゃない？＞新人様 「悪い設計を正しくコーディングしても意味は無い」 「悪いコードは、悪い設計者を育てる」 オブジェクト指向だから拡張性・保守性が高いわけでは、ありません。 拡張性・保守性を高くしたいからオブジェクト指向で設計するのです。 | ||||||||
|
投稿日時: 2004-06-16 14:26
Takiroです．ご意見ありがとうございます．少し端折りすぎて当方の意図を理解してもらえなかったかと心配しておりましたが，正しく汲み取っていただけたようで安心しました．
『ユーザ要求』＝成果物，『システム要求』＝部品という解釈で間違いないでしょうか？ その前提で， 部品を作ってゆき成果物をなるべく部品またはその組み合わせを多用して構築する姿勢が，オブジェクト指向を利用すると構造化よりも実現しやすいということと解釈しましたが，間違いないでしょうか？ その意味で，私の投げた問いかけである『機能変更』への強さが，"部品の使いまわしにより"実現されるということですね．
このあたり少し実感が湧きにくいのですが，難しくなければ，何か具体的な例を紹介していただけると助かります． あと誤字(責務⇒債務；これは誤字とは呼べませんね，事態⇒自体)，失礼しました． | ||||||||
|
投稿日時: 2004-06-16 14:33
本筋じゃないですが、一点だけ・・・ 責務であってますよ。 債務だと、借金背負っちゃいます。 | ||||||||
|
投稿日時: 2004-06-16 15:10
Takiroです．ご意見ありがとうございます．
わかりやすい実例まで示していただき，理解しやすかったです(しかし間違ってるかも．．．)．
字を間違えたし，よく理解できてなさそうな部分なので間違っていたら指摘願います． tak3さんに説明いただいた具体例を含めた解釈なのですが，間違いありませんでしょうか？ 機能自体は同じように変更を受けることに変わりはない． しかし機能が適切に配分されているため，変更が発生しても影響は最小限に押さえられる． tak3さんの機能分担案に当てはめた場合， 『機能あ・い』が変更を受けることは案Aも案Bも違いはない． しかし，『機能あ・い』の変更に伴う，その他の変更が発生するのを案Bでは『データ』だけに押さえ込めます． ということですね． 案Aでも，やり様によっては他に影響を及ぼさないようにできるが，オブジェクト指向プログラミングで， ・データと振る舞いを『クラス』という線引きの中に入れてしまえる ・カプセル化により外からの影響を最小限にできる というサポートが得られやすいので，『そうしたい！』を実現しやすいですよ． と解釈しました．おかしなこと言っているようでしたらご指摘ください． | ||||||||
|
投稿日時: 2004-06-16 15:20
とんだ赤っ恥でした． 念のため書き込み前に辞書調べたのですが，どっちでも意味が通りそうなところが始末に終えませんよね． これも本筋とは関係ないですが，yahoo!での検索結果 ・『オブジェクト指向＆責務』⇒ 1097件 ・『オブジェクト指向＆債務』⇒ 288件 | ||||||||
|
投稿日時: 2004-06-16 16:00
るぱんです。
責務と債務調べてみました。 責務 債務 個人的には「義務」って言うのはなんか違うと思うのと、 「債」って元々金融関連の言葉ですよね？って思って責務が正しいと思う次第です。 [ メッセージ編集済み 編集者: るぱん 編集日時 2004-06-16 16:03 ] | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.