|
|
|
|
コメント(111)
確かに水掛け論になりそうなんでそろそろやめときたいですが。
手続き型プログラミングで苦労した人が、OOを教えられて一気に開眼するということは有ると思います。
プログラミングをまったく知らない人に最初に教えるのがOOだと言う場合、JAVAやC++の教科書に載ってるような数10行のtoyプログラム(有用性を示す断片が数10行じゃなくて、一切合切ひっくるめ手数10行ですよ!)では、どうも有用性が理解できないようです。OOを使わないとどうなるかを知らないわけですから当然といえば当然かも。
うっかり放っておくと、メソッドの引数は無し、データはグローバル変数で渡すなんてプログラムをJAVAで書いてみたり。
自分で痛い目を見ないと落とし穴を避ける癖がつかないのが凡人。人の振り見て我が振り直せるのが有能な人。というのが学生を見ている感想です。
手続き型プログラミングで苦労した人が、OOを教えられて一気に開眼するということは有ると思います。
プログラミングをまったく知らない人に最初に教えるのがOOだと言う場合、JAVAやC++の教科書に載ってるような数10行のtoyプログラム(有用性を示す断片が数10行じゃなくて、一切合切ひっくるめ手数10行ですよ!)では、どうも有用性が理解できないようです。OOを使わないとどうなるかを知らないわけですから当然といえば当然かも。
うっかり放っておくと、メソッドの引数は無し、データはグローバル変数で渡すなんてプログラムをJAVAで書いてみたり。
自分で痛い目を見ないと落とし穴を避ける癖がつかないのが凡人。人の振り見て我が振り直せるのが有能な人。というのが学生を見ている感想です。
Javaを覚えたての学生でも、実践的なプロジェクト実習の中で指導していくと、どんどんオブジェクト指向っぽいプログラムを書けるようになっていきますよ。まずは動くプログラムを自分で書かせて、その後でオブジェクト指向っぽく書くとどうなるかを理由つきで解説してやると、身につくようです。初心者でもよいプログラムと悪いプログラムの比較はできますからね。（逆に比較すらできない人は、どんな言語でもまともなプログラムは書けないでしょう。）
デザインパターンも書籍で勉強させるより、自分で書いたコードに後から適用して説明してあげるのがいいと思います。開発プロジェクトの中だとデザインパターンが必要となる理由も明らかですから、理解し易いようです。ただ、このような教育はひまな大学だからできる話なのかもしれません。
デザインパターンも書籍で勉強させるより、自分で書いたコードに後から適用して説明してあげるのがいいと思います。開発プロジェクトの中だとデザインパターンが必要となる理由も明らかですから、理解し易いようです。ただ、このような教育はひまな大学だからできる話なのかもしれません。
がると申します。
ちと内容的に興味が引かれるので参戦を。
んと…とりあえずまず。皆様に質問をしてみたいのですが。「OOはなぜ難しいか」という文脈におけるOOをどんな風に定義してらっしゃるんでしょうか？
というのが。
私は「OOなんて簡単じゃん」派なのですが。それは、見方を変えると「OOという概念のなかから、とりあえず簡単に使える上にうまみのでっかい部分を取り出して使う」傾向が高いからでもあります。
なので、そのあたり、いろいろな方のお話を伺ってみたいかなぁと思うのですが如何でしょうか？
もし全員の共通見解が出なかったとしてもなお、多くの方にとって「様々な意見を知る事が出来る」のは、とても大きな事だと思うのですが。
ちと内容的に興味が引かれるので参戦を。
んと…とりあえずまず。皆様に質問をしてみたいのですが。「OOはなぜ難しいか」という文脈におけるOOをどんな風に定義してらっしゃるんでしょうか？
というのが。
私は「OOなんて簡単じゃん」派なのですが。それは、見方を変えると「OOという概念のなかから、とりあえず簡単に使える上にうまみのでっかい部分を取り出して使う」傾向が高いからでもあります。
なので、そのあたり、いろいろな方のお話を伺ってみたいかなぁと思うのですが如何でしょうか？
もし全員の共通見解が出なかったとしてもなお、多くの方にとって「様々な意見を知る事が出来る」のは、とても大きな事だと思うのですが。
Sahmaroさん
>OOA はオブジェクトの抽出と抽出したオブジェクトの関係を明確化する作業だと思っていますが、違いますか？
ちょっと分からないので確認させていただきたいのですが、
1. 抽出は完成した仕様書からされるのでしょうか？それとも、要件定義をしている途中段階でするのでしょうか？
2. 抽出したオブジェクトやそれらの関係は、どう記述するのでしょうか？クラス図でしょうかオブジェクト図でしょうか？
3. 記述したものは、設計工程で使うのでしょうか、それともそのまま実装工程に引き継がれるのでしょうか？別の質問をすると、記述したものは誰が見るのでしょうか？
私の予想ですが、OODでなくOOAというからには、設計よりも前の段階で行われるのでしょう。そうすると出来上がったものは、設計図よりも抽象度が高いもののはずです。私の疑問は、そんな抽象度の高い図を作成して一体誰が嬉しいのかということです。そんなもの見るより、自然言語で丁寧に書かれた仕様書の方がずっと当てになるように思うのですが、いかがでしょうか？
>OOA はオブジェクトの抽出と抽出したオブジェクトの関係を明確化する作業だと思っていますが、違いますか？
ちょっと分からないので確認させていただきたいのですが、
1. 抽出は完成した仕様書からされるのでしょうか？それとも、要件定義をしている途中段階でするのでしょうか？
2. 抽出したオブジェクトやそれらの関係は、どう記述するのでしょうか？クラス図でしょうかオブジェクト図でしょうか？
3. 記述したものは、設計工程で使うのでしょうか、それともそのまま実装工程に引き継がれるのでしょうか？別の質問をすると、記述したものは誰が見るのでしょうか？
私の予想ですが、OODでなくOOAというからには、設計よりも前の段階で行われるのでしょう。そうすると出来上がったものは、設計図よりも抽象度が高いもののはずです。私の疑問は、そんな抽象度の高い図を作成して一体誰が嬉しいのかということです。そんなもの見るより、自然言語で丁寧に書かれた仕様書の方がずっと当てになるように思うのですが、いかがでしょうか？
Sahmaroさん：
複雑なシステムでOOAが必要ということでしたので、てっきり大人数で開発されているのかと思いました。１人で創っているということでしたら、私の89の質問は完全に的外れでしたね。失礼いたしました。
イチローさん：
私の「抽象的」という言葉がまずかったかもしれません。なぜその仕様にしたのかとった情報は確かに大切なのに抜け落ちがちなものですね。そういう情報の必要性についてはよく理解しているつもりです。
図の重要性についても理解しているつもりです。そういう意味で、84でユースケース図やER図は上流でも使えそうだと書いたつもりなのですが、実はユースケース図もER図も純粋なOOではないんですよね。仮に分析工程でクラス図を描くとしても、ほとんどがER図的にしか使っていないんじゃないかと想像しています。
あまり上流でクラスのようなものをがっちりと定義してしまうと、それが一人歩きしてしまうのではないかという懸念があります。
複雑なシステムでOOAが必要ということでしたので、てっきり大人数で開発されているのかと思いました。１人で創っているということでしたら、私の89の質問は完全に的外れでしたね。失礼いたしました。
イチローさん：
私の「抽象的」という言葉がまずかったかもしれません。なぜその仕様にしたのかとった情報は確かに大切なのに抜け落ちがちなものですね。そういう情報の必要性についてはよく理解しているつもりです。
図の重要性についても理解しているつもりです。そういう意味で、84でユースケース図やER図は上流でも使えそうだと書いたつもりなのですが、実はユースケース図もER図も純粋なOOではないんですよね。仮に分析工程でクラス図を描くとしても、ほとんどがER図的にしか使っていないんじゃないかと想像しています。
あまり上流でクラスのようなものをがっちりと定義してしまうと、それが一人歩きしてしまうのではないかという懸念があります。
92 おとんさん
確かに紛らわしい書き方をしていましたね。申し訳ありませんでした。
私は４年近く前に Tucker!著「憂鬱なプログラマのためのオブジェクト指向開発講座」という書籍を読んでかなり衝撃を受けました。
この書籍では最後に魔法陣を対象に分析・設計・実装が記載されているのですが、分析からクラス図を扱っており実装までシームレスに作業が流れている点は驚きでした。と、同時にこのような小さな問題領域にも適用できるものだということを知った次第です。
さらに分析がなければここに提示された実装には至らないであろうと感じました。
ですので、みなさんプロの方は分析に時間をかけているのかと想像していましたが必ずしもそうではないようですね。
確かに紛らわしい書き方をしていましたね。申し訳ありませんでした。
私は４年近く前に Tucker!著「憂鬱なプログラマのためのオブジェクト指向開発講座」という書籍を読んでかなり衝撃を受けました。
この書籍では最後に魔法陣を対象に分析・設計・実装が記載されているのですが、分析からクラス図を扱っており実装までシームレスに作業が流れている点は驚きでした。と、同時にこのような小さな問題領域にも適用できるものだということを知った次第です。
さらに分析がなければここに提示された実装には至らないであろうと感じました。
ですので、みなさんプロの方は分析に時間をかけているのかと想像していましたが必ずしもそうではないようですね。
広い世の中には、ろくにプログラミングもできないくせに分析とか設計をやっている人もいたりするんでしょうか？ちょっと心配してます。
ソフトウェア工学の歴史は概ねプログラミングパラダイムの変化を契機として発展してますよね。構造化プログラミング→構造化設計→構造化分析のような形で。
OOA/OODもOOPがあって出てきたものですが、そんなに単純に話が進んでいるわけでもないようです。UMLで有名なスリーアミーゴは、UPではユースケースドリブンを根幹に位置づけています。欧米では、「要求定義書にあらわれる名詞をオブジェクトとみなして。。。」なんて素朴な捉え方は、最近どうも廃れてきているようにも見えます。一部の熱狂的な信者によって支持された時代から、広く実務で生かされる時代へと成熟してきたのかなぁ、なんて想像しています。まぁ単に「OOAなんて胡散臭い」という先入観で私が見ているだけの話かもしれませんが。。。
ソフトウェア工学の歴史は概ねプログラミングパラダイムの変化を契機として発展してますよね。構造化プログラミング→構造化設計→構造化分析のような形で。
OOA/OODもOOPがあって出てきたものですが、そんなに単純に話が進んでいるわけでもないようです。UMLで有名なスリーアミーゴは、UPではユースケースドリブンを根幹に位置づけています。欧米では、「要求定義書にあらわれる名詞をオブジェクトとみなして。。。」なんて素朴な捉え方は、最近どうも廃れてきているようにも見えます。一部の熱狂的な信者によって支持された時代から、広く実務で生かされる時代へと成熟してきたのかなぁ、なんて想像しています。まぁ単に「OOAなんて胡散臭い」という先入観で私が見ているだけの話かもしれませんが。。。
> がるさん
> ・OOは、OOPやらOOAやらOODやら色々な概念を包括しているはずなのだが、実際にはOOというとそのままOOPに直結してしまい、OOの中にOOAとかが入ってることを失念してしまっている人が多い
> 実際、私もあちこちで話をして、OOの話をしているのになぜかOOPに固有の話と混合されてしまうことが多いというのは実体験としてあるので。
御意。
このトピでも「OOは簡単」というコメントが出ていますが、おそらく「OOPは簡単」という意味だと推察します（もしOOADは簡単というなら僕の勘違いですが）。とすれば、この「OOは簡単」というコメントを違和感なく受け取る方はOO=OOPという常識があるからではないでしょうか。
OOが難しいという方とOOが簡単という方たちの認識がすれ違っているように思えます。
> おとんさん
> 広い世の中には、ろくにプログラミングもできないくせに分析とか設計をやっている人もいたりするんでしょうか？ちょっと心配してます。
いると思います。
実際、今の僕のいる現場にも結構います。
> ・OOは、OOPやらOOAやらOODやら色々な概念を包括しているはずなのだが、実際にはOOというとそのままOOPに直結してしまい、OOの中にOOAとかが入ってることを失念してしまっている人が多い
> 実際、私もあちこちで話をして、OOの話をしているのになぜかOOPに固有の話と混合されてしまうことが多いというのは実体験としてあるので。
御意。
このトピでも「OOは簡単」というコメントが出ていますが、おそらく「OOPは簡単」という意味だと推察します（もしOOADは簡単というなら僕の勘違いですが）。とすれば、この「OOは簡単」というコメントを違和感なく受け取る方はOO=OOPという常識があるからではないでしょうか。
OOが難しいという方とOOが簡単という方たちの認識がすれ違っているように思えます。
> おとんさん
> 広い世の中には、ろくにプログラミングもできないくせに分析とか設計をやっている人もいたりするんでしょうか？ちょっと心配してます。
いると思います。
実際、今の僕のいる現場にも結構います。
- mixiユーザー
- ログインしてコメントしよう！
|
|
|
|
オブジェクト指向が苦手 更新情報
-
最新のイベント
-
まだ何もありません
-
-
最新のアンケート
-
まだ何もありません
-
オブジェクト指向が苦手のメンバーはこんなコミュニティにも参加しています
人気コミュニティランキング
- 1位
- 食べ物写真をつい撮ってしまう人
- 19179人
- 2位
- 広島東洋カープ
- 55353人
- 3位
- 暮らしを楽しむ
- 75419人