＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
オブジェクト指向の理解度を測るためには？
| 投稿者 | 投稿内容 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-06-10 12:23
以前、日経ソフトウェアで、オブジェクト指向習得度チェックポイントの図があったので
WEBで検索したらちゃんと記事がPDFでありました。 http://software.nikkeibp.co.jp/software/contents/2002/0202index.html 特集１ 「オブジェクト指向知識から実践」 なにぶん古いので実物は手に入らないと思います。 もうひとつ重要な（と個人的に思う）図が本誌では書いてあるのですが、この図でもそれなり の判定材料に使えると思います。 アンケートについては、 設問１については、ハードルが高いというよりも、はにまるさんと同様に面倒くさいというのが感想です。 オブジェクトの粒度って、絶対に人それぞれでバラバラになりがちなので、回答をもらっても 理解してるか判断し難いところですよね。 今回の場合、自分だったら・・・ 自動販売機 製品（ジュース） クライアント（太郎君）の３つで終わらせちゃいますよ。 金額表示インジケータとか購入ランプは、ぶっちゃけ書く気がしないなぁ・・・ それこそ内部構造まで詳細にやっていったらキリがないでしょう・・・（冷蔵装置、保温装置、内部温度計 etc） | ||||||||||||||||
|
投稿日時: 2004-06-10 12:26
じゃあ、10択くらいで 「この中でオブジェクトになれるのはどれですか？すべて答えなさい」 みたいな設問にしてはどうでしょう？ 選択肢を工夫する必要はあると思いますが。 （ちなみに、この手法は某書籍から拝借したものです (^^; ） # う〜ん、浅い知識で挑むと大変だわ（苦笑 ←自己ツッコミ） | ||||||||||||||||
|
投稿日時: 2004-06-10 12:52
Ｍｉｃｋｙでございます。
遅まきながら、私も混ぜてください（＾＾； 「オブジェクト指向」(というモノ)を理解すると言うことであれば、 自分はやはり、まず「オブジェクト指向言語」からは離れた方がいいと思うんですよ。 「オブジェクト指向」はあくまで考え方であって、 実現方法はあとからついてくるものじゃないでしょうか？ だから、「オブジェクト指向言語」じゃなくたって、 「オブジェクト指向」で設計して、多少無理やりでもそれなりに 実現できていれば、やっぱり「オブジェクト指向」だと思います。 じゃ、「オブジェクト指向」ってなに？って事になると、 自分は「モノの性質を理解しオブジェクトとして考える」って事だと思うんですね。 実際の業務では単純に物理的な「モノ」として捉える事ができるものもありますが、 そうでないものもあります。 そんな時は「擬人化」や「擬物化(こんな言葉はありませんが）」して内包するデータや 振る舞い（責務）を分析、定義して行く事が「オブジェクト指向」だと思っています。 とすると、当然データのないクラスもあるでしょうし、振る舞いのないクラスが 存在してもおかしくないと思うんですね。 だから、「データ中心」とか「振る舞い中心」って言うのは、自分としては やっぱりピンとこないんです（＾＾； で、「オブジェクト指向」の考え方を容易に実現する方法として用意されたのが 「オブジェクト指向言語」って事になるんではないでしょうか？ 一連の「オブジェクト指向用語」はあくまで「オブジェクト指向」の 考え方を容易に理解、利用する手段ではないかと思うわけです。 オブジェクト指向プログラミングと構造化プログラミングについて…
わたしも、同意見です。（＾＾） クラスの中のメソッドが、何百行もあって…なんてのは、 しゃれになりませんものね。 構造化プログラミングありきの、オブジェクト指向プログラミングであると思います。
問題ですが、自分なら相当悩みます（＾＾； まず、太郎君もオブジェクトとして抽出させる事も望んでいらっしゃいますか？ とすると、まず、太郎君と自販機の挙動を分析する所から入ると思うので、 クラス設計というより「ユースケース図」ありきの様な感じもするのです。 太郎君を単なるアクターとしたとしても、クラスとして抽出されるのは やはりまず、「自販機クラス」ですよね？ ＞ ただし、必ず”自動販売機クラス”を作成してください。 と言うよりは、まず「自販機」をクラスとして抽出するか否か？ってのが 実力を測る指針になるような気もします。 自販機クラスを抽出したあとですが、これが難しいです（＾＾； 太郎君が買い物をする事だけに対する「自販機の機能」に焦点をあてるのか、 「自販機自体」をいかに完璧なクラスとして成立させるのか、 どちらを意図しているかによってかなり違ってくると思いますし、 「完璧な自販機クラス」を目指す場合、どこまでの粒度で 「自販機」を分解するのかも問題になるように思ってしまいます。 なんかいい例題がないかただ今考え中です。 なにか思いついたらまた書き込みさせていただきますね。 | ||||||||||||||||
|
投稿日時: 2004-06-10 17:32
いえ、バックナンバーは残っているみたいですよ。こちらの一番下 また、縮刷版という手もあります。こちら | ||||||||||||||||
|
投稿日時: 2004-06-10 17:51
ごめんなさい。 このレスを見逃してました。 勉強してる人と勉強していない人に分かれるんですよね？ 分けたら良いんじゃないですか？ 勉強していない人に「ある一定の基準まで」勉強してもらって、 全員が同じ下駄を履いた状態から、同じ様に解説していけたら良いんじゃないかな・・・？ ただ、僕だったら先に、やる気の無い人に対してどうするか 自分と相手の上司にお許しを頂きますね。。。 「どんな手を使っても理解させる」事を第一優先に考えた結果ですが・・・。 そうでない場合は、「教育しろ！」命令を反故にしてもいい状況作らざるを得ないわけです。 | ||||||||||||||||
|
投稿日時: 2004-06-10 18:08
意見に躊躇していましたが．．．言っちゃえ！ 
まず「オブジェクト指向言語でのプログラミング」と「構造化プログラミング」の違いは、 １．ロジック分割／集合の表現と実装方法の違い。 ２．分割／集合されたロジックの利用方法（呼出方）の違い と捉えています。 つまり「オブジェクト指向言語」であっても最終的に「構造化プログラミング」する 必要がありますし、オブジェクト定義する事自体が生産を上げる訳で無く、 オブジェクトで定義して処理するより「値」その物や「手続ロジック」で表現した方が 生産性が高い事は、極々普通にあります。 # 例： # 「性別」の情報が存在し、その内訳内容として「男」と「女」を考える場合 # 「男」自体、「女」自体は、オブジェクトに成り得ます。しかし実際には、 # これをオブジェクトでは無く、「１」や「２」の区分値で表現管理します。 # これはシステム上、男や女をオブジェクト定義して管理する意味が無く、 # 値レベルの再利用は有り得無い為です。 # こう記述するとＤＢの正規化と話が似ていますね。 また、クラス図でオブジェクト（クラス）同士の関係を多種記述しても それをプログラム表現する場合はパターンが限られ、その表現の多くは、 構造化プログラミングの表現手段と同一である事も包括的要素の多い理由として 挙げられると考えます。 # これは私が表現パターンを知ら無いだけの可能性が大きいですが．．． 以上の考えより、『共存する、或いは包括的要素の多いもの』は、 私も存在すると考えています。 後『オブジェクト指向的アプローチで設計、構造化プログラミングをする』は 設計時にオブジェクト間の関係パターンに制約が入り表現出来ない箇所もありますが、 オブジェクト指向で設計する事は、オブジェクト指向で実装する事が目的では無い為、 構造化プログラミングへ効率的に変換するコツ、又はオブジェクト定義の止め時を 知っていれば非常に有効であると考えます。 ただ、コツを知らずしてオブジェクト指向で設計し実装すると、分割したクラスを元に戻して 再設計する後戻り作業が増える為、非生産的です。（これは経験談） [ メッセージ編集済み 編集者: はにまる 編集日時 2004-06-10 18:10 ] | ||||||||||||||||
|
投稿日時: 2004-06-10 18:27
るぱんです。
いつもながら取り留めない意見です。
生産性云々以前に個人が習得するべき事の幅が広すぎると言う風に思います。 以前であれば、 ネットワークはネットワーク屋 ＤＢはＤＢ屋 ある程度の切り分けが合ったと思います。 もちろん個人で全てをこなされる方も多いと思いますが。 全てを一人にかぶせてしまって、情報隠避ならぬ「問題隠避」で 「解決した気分」になっていただけではないでしょうか？ きちんと切り分けて、餅は餅屋にやらせるとすれば、 生産性は劇的に上がると思います。
これも先ほどの意見と変わらないのですが、 あらゆる要素を一つの思想で幅広くサポートできるようになっているが故の 問題点だと思うんですね。 抑えるべき基本的な要素が増えていても、人間がついていけなくなった・・・ 状態なのではないでしょうか？ 個人的な欲求ですが、キッチリ切り分けて、 「目の前の一つ」に集中できる環境が欲しいです。
たしかに。。。 やりすぎると痛い目見ますしね。 さじ加減って大事ですよね。（冷汗） 本音を言えば、全員が平均的なスピードで動くか、 個人に押し付けるなら、時間が欲しい・・・と言うのが本音ですね。 | ||||||||||||||||
|
投稿日時: 2004-06-10 21:09
こんにちは。
スレッド主さんにそう言ってもらえると嬉しいです(ってことで色々と書いてみますです)。 ぼくの考えは基本的には、Ｍｉｃｋｙさん：2004-06-10 12:52の投稿と同じ意見です。 オブジェクト指向の話でプログラミング言語の話が入ってくると、 非常にわかりづらくなってしまうように思います。 オブジェクト指向でよく言われる「現実世界をそのままモデリングする」というのは、 概念レベルの分析・設計の話で、それを実装レベルの話に置き換えてしまうのは相当無理があるように思われます。 「情報隠蔽」「カプセル化」という用語をとってみても、この二つの言葉はまったく違う意味です。 （詳しくはこちら） オブジェクト指向の本質としては、ぼくは以下の情報源を標榜しています。 http://www.atmarkit.co.jp/fjava/devs/renew_uml01/renew_uml01.html http://jibun.atmarkit.co.jp/lskill01/rensai/hagimoto04/hagimoto01.html この中で著者の方が繰り返し説明しているのは、
即ち、オブジェクト指向を使うことで純粋にソフトウェアの構造だけを表現できる (細かいロジックはクラス内部に隠蔽できる) それによって、モデルを見る人がわかりやすいことが、 オブジェクト指向の本質になる。ということです。 今いったことは上流工程の話ですが、 上流工程で行ったことを下流工程に綺麗に落とせることもオブジェクト指向の利点だと思います。 その概念モデルから実装モデルへのマッピングを行うのがアーキテクトの役割(？)。 上流から下流への一貫した考えを行うことで、仕様変更にも柔軟に対応できることに繋がります。 (こういうところで構造化技法とは違った意味の再利用性なのかなぁ。。) 以上、実践経験ゼロの素人の考えでした。 _________________ 『Life's rich Tapestry!!』 | ||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.