＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
オブジェクト指向の理解度を測るためには？
| 投稿者 | 投稿内容 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-06-15 11:43
ええと、これは私の私見なのですが。
UML は簡単なクラス図を描くだけにせよ、それなりの修練が必要な技術だと思っています。 「オブジェクト指向の理解度を測るためには？」 に則するのなら、既に何度か出ているレスのように、簡単なコードを書いてもらった方がよい気がするのですが、いかがなものでしょうか。 # 決してモデリングを軽視しているのではありません。 # 入り口のハードルが高いように感じるだけです。 あとは、定量的に理解度を見るのでしたら、やはり設問形式で採点するか、か…。 mso さんの会社では、プログラマを育てたいのとは違うのかしら。設計方面なのかな。 …どんなことでもそうですが、使わないと本当の理解は得がたいでしょうし、使えなければ意味がありません。厳しいことを言うようかもしれませんが、仕事ってそうですよね。 ちなみに、私は完璧主義者ではないですよ（笑）。使っているうちに味が出てくればよいのではないでしょうか。 私のオブジェクト指向歴（笑）は、鼻息で飛んでしまうほど短いのですが、脱落していった方や、よく分からないけど偉ぶっている方は、その間だけでもけっこう見ることができました。 いまはどうしているんでしょうね。 このスレに参加できて、ちょっと嬉しく思っています。 はにまる さんへ＞ その本 はこちらのスレでもご紹介しましたよ（笑）。 「著者は ”リファクタリング” の翻訳者のおひとりです」 と書こうかと思いましたが、あのときはやめておきました。 読了の際には、別スレにも所感などをお寄せくださいね（笑）。 ## 日本語を微妙に直しました… [ メッセージ編集済み 編集者: はゆる 編集日時 2004-06-15 13:28 ] | ||||||||||||||||
|
投稿日時: 2004-06-15 14:16
Ｍｉｃｋｙでございます。
「オブジェクト指向」と言っても、いろんな側面があり みなさんのいろんな意見が聞けるので、興味深く読んでいます。
同感であったりします（＾＾）
そういう面もあるかなぁ？とも思いますが、 ＵＭＬクラス図のどの部分が一番「ハードルが高い」と思わせているのでしょう？ もしかして、モデリングツールの使い方の問題でしょうか？ 私としては、まず「クラス図ありき」だと思うんですよ（＾＾； 今はＵＭＬがスタンダードですが、「オブジェクト指向」を始めた頃は 雲の図（Ｂｈｏｏｃｈ）をずっと書いてました。 ＵＭＬの四角の方がスペースも取らないし、手書きにも向いていますよね。 そこで、裏紙でもメモ用紙でもいいんで、 なんらかのオブジェクトについて、 「四角を書いて、中に２本線を引いて、クラス名、属性、メソッドを書く」 そうすれば、クラス図一個できますよねぇ？ これって、そんなに難しいと思わないし、まず、これが入り口だと思っています。 「モデリング」って言うと結構大層に聞こえちゃいますが、 これでも、立派にモデリングしてると思うのですがいかがでしょう？
コードだと、問題は何をコーディングしてもらうか？になりますよね。 コードでクラスを作ってもらいますか？ だとしたら、ちょっと違うような気がします。 頭の中にある「クラス」をいきなりコードにするという行為は 例え試験的なものだとしても、よくない方向の様に思います。 クラス図−＞コード化 というマッピング作業ならわかるのですが… これ以外でコードで表現する「オブジェクト指向」って クラスライブラリの使い方とか、Ｎｅｗの仕方とかになるのかなぁ〜 とすると、「オブジェクト指向」というより文法的な色が濃い様に思います。 それこそ「またがってる系」になりそうに思うのですが、危惧しすぎでしょうか？（＾＾； ＵＭＬじゃなくてもいいので、クラス一個でいいから、 なにかのオブジェクト(よくあるの乗り物とか？）についてのクラスの図が書けるか？ これが「できるレベル／できないレベル」で大きく分けられるように思います。 | ||||||||||||||||
|
投稿日時: 2004-06-15 14:23
あ！本当だ〜
お！トリビア〜ン  （「レ」じゃなく「リ」だよ！）
え！感想文は苦手です．．．ただ、現時点の答えは出ています。（早！ 簡単な話、「オブジェクト指向」を理解しただけでシステムを開発出来ません。 それは、きっと誰しもが理解しているのですが、実際に呪縛を解くのは難しいと思います。 スレッドタイトルのまま考えた場合、問題になるのが「クラスの切出し方」です。 これが出来なければ、「継承」も「ポリモルフィズム」も「クラス化」もありません。 「クラスの切出し」に必要となる知識は？と平素に考えれば構造化時代から変らず 結局の所、「プログラム構成設計」技術になります。 「プログラム構成設計」は更に、ＯＳ、ＤＢ、ネットワークの基礎知識、分割技法、 データの処理概念に知識分類が出来ると思います。 つまり 「オブジェクト指向」での混乱とは、旧態のシステム開発から元々存在した、 曖昧な技法や問題が表に出ただけであって「オブジェクト指向」自体の問題では無い。 と考えます。ですから、私は「システム開発自体」のスキルアップや作業改善の方針や道具 として「オブジェクト指向」全般の技術があると捉える事が自然と思います。 旧態のシステム開発で置き去りした、曖昧な技法や技術をそのままで 「オブジェクト指向」を求める事には無理があると考えます。 | ||||||||||||||||
|
投稿日時: 2004-06-15 15:05
Ｍｉｃｋｙ さんのおっしゃることはとてもよく分かります。 私も 「お絵かき」 は大好きです。
私が 「ハードルが高いんじゃ…」 と思った理由は… 例えば、Ｍｉｃｋｙ さんが先に例に出された 「図形クラス」 をお絵かきする場合、継承部分ってどう描けばいいのかが分からなかったんですね（爆）。 好き勝手にお絵かきできれば何とかなりそうな気もするのですが、それだと 100人分を見るときにツライかな、と…。 
そうなると、一定のフォーマットが必要になり、お絵かきの仕方をまず頭に入れなければならなくなりますよね。 だったらコードを書いてもらった方が早い？（双方にとって負担が少ない？）と思ったわけです（苦笑）。 # すいません、プログラマー頭なだけですね私… | ||||||||||||||||
|
投稿日時: 2004-06-15 15:37
> クラス図−＞コード化 というマッピング作業ならわかるのですが…
これはある程度ＯＯＰの経験を積んだ人だからいえる言葉でしょう。 対象者のレベルがはっきりとしない状態を想定しているスレッドですから やはりいきなりモデリングという抽象作業から入るのは危険だと 私は考えます。 なぜならまず紙の上でのモデリングではデバッグが効きません。 クラスライブラリから派生した無理な継承関係を作ろうとした場合でも、 コード上であれば訂正してもらえます。 > コードだと、問題は何をコーディングしてもらうか？になりますよね。 > コードでクラスを作ってもらいますか？ Ｍｉｃｋｙさんは実装工程は別の人がやるという考えから こういう風に仰っているのかも知れませんが、これもこれから ソフトウェア開発を行っていくという人には危険な考えだと思います。 なぜならソフトウェアは動作して初めて意味があるからです。 モデリングから始めた場合、どうしても理論先行になり、 「ここはオブジェクト指向していない」と言った理由で、実装上の 分かりやすさを損なったり、パフォーマンスを度外視したりしてしまうことが 考えられますが、それでは本末転倒ではないでしょうか？ > そこで、裏紙でもメモ用紙でもいいんで、なんらかのオブジェクトについて、 > 「四角を書いて、中に２本線を引いて、クラス名、属性、メソッドを書く」 > そうすれば、クラス図一個できますよねぇ？ > これって、そんなに難しいと思わないし、まず、これが入り口だと思っています。 こういったレベルであればコーディングの方がむしろ手っ取り早くはないですか？ ＸＰの今必要でないものは組み込まないという思想を適用すれば、 モデリング作業はある程度形ができてからはじめて行うべきものだと私は思います。 どちらかと言えばリファクタリングに近いでしょうか？ 勿論すでに開発対象の経験があり、なにをつくるべきかが明らかになっている 場合は別ですが、それはこのスレッドの意図するところではないでしょう。 [ メッセージ編集済み 編集者: lang8 編集日時 2004-06-15 15:41 ] | ||||||||||||||||
|
投稿日時: 2004-06-15 18:40
永井です。なんか乗り遅れた感じですが、へたれな私も少し参加させてください。
そうかも知れませんし、そうでないかも知れません。 が、UML自体の習得コストに関してはそれ単体では無く、他の表記法とのみ比べられるべきだと思います。 どの実務でも、1人で全て設計・実装するというのでしたら問題無いのですが、現実的にはその可能性は低い(/というより、ほぼ有り得ない)ですよね？ そうすると、社内(/ステークホルダー内)での何らかのアウトプット標準は必要になってくるわけで、その中の有力な選択肢としてUMLがあると思います。他の表記法でも構わないのですが、とにかく何かしらの統一書式を定めることになるのではないかと。バラバラだと、毎回書式を理解するところから始めなくてはならず、非効率ですから。 形式だけでなく、実務(/実利)に直結させると考えると、書式のマスターのためにコストをかけることは浪費ではありません。これを機に「オブジェクト指向自体はOKだけど、UMLはちょっと……」という方にも、マスターする機会を与えてあげるのがいいと思います。 まあ、単純な習得コストだけではなく運用コスト(社外ステークホルダーとの接続性や新入社員の教育コスト)に関しても考慮する必要はあり、現実的な解としては、やっぱりUMLに落ち着くような気がしないではないですが。 で、本題。
十分なコストをかけることが許されているのなら…… ・前提条件としてUML(/社内標準表記法)を理解してもらう ・ユースケース図を渡して要件説明。クラス図を生成してもらう ・クラス図を起こした本人を交えてレビュー(1回目) ・クラス図を元に実装してもらう ・本人を交えてレビュー(2回目)。実装に際してクラス図を修正した場合等はその辺りを特に突っ込む ・多態を用いて対応出来るような機能追加を要請。クラス図の修正、コードの修正・追加をしてもらう。出来れば、想定されていた箇所、想定されていなかった(インターフェース化されていない)箇所両方が望ましい ・本人を交えてレビュー(3回目) ……としたいところです。すみません、欲張り過ぎですよね(汗 思考過程を重視したいからレビューもやりたいし、現実と乖離した理想に走らないためにコードも書いてもらいたいという考え方です。すでに、はにまるさんやMickyさんが書かれていますが、特に思考過程を重視したいのでレビューは絶対に外したくないですね。 まあ、ちょっと贅沢にコストを掛けすぎている夢物語で、しかも教育フェーズ自体を内包しちゃっているような気がしなくもないのですが。 上のような流れに対応出来れば、大体は実務でも「地に足がついた設計」が行えるのではないかと思います。 でも、正直100人にこれは大変かなー…… [ メッセージ編集済み 編集者: 永井和彦 編集日時 2004-06-15 19:43 ] | ||||||||||||||||
|
投稿日時: 2004-06-15 18:56
＃本題からは、ずれた投稿ですm(__)m
マーチン・ファウラー特別ラウンドテーブルにも参加されていらっしゃったみたいです。 「オブジェクト指向でなぜ〜〜」は、まだ少しだけ立ち読みしたばかりですが、とても理解しやすい形でまとめられていました。 自分の未熟さを感じています。(間違ったことを言ってるつもりはないけれど) _________________ 『Life's rich Tapestry!!』 | ||||||||||||||||
|
投稿日時: 2004-06-16 08:49
“学校方式”で、「個人個人がどの程度であろうが、同じことを同じように教える。上の方にいるヤツは最初は暇かもしれないけれど我慢してね。最後には、みんなが同じ程度のレベルになるでしょう」じゃダメ？ | ||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.