Javaに関する様々な情報をご紹介します。

Javaに関する様々な情報をご紹介します。
評価

0

オブジェクト指向の教育について

入社1〜2年目程度の新人向けに、
オブジェクト指向研修を行おうと考えています。

具体的な対象者のレベルは、
・入門書を一通り読んで基本構文・用語は理解済み。

・「クラスAを継承したクラスBを作りなさい」とか、
 「xxインターフェイスを実装したクラスC・Dを作りなさい」とか
 を指示すれば、問題なくコーディング出来きる。

・インスタンス(マルチプル)の理解が怪しかったり、
 簡単な処理を実装させると、思いっきり構造化プログラミングに
 なってしまう。
 
言語の構文レベルではなく、オブジェクト指向の理解が不足していると感じ、
研修を企画している次第です。

そこで皆様に質問です。
【有識者の方へ】
 上記レベルの初心者に、「オブジェクト指向プログラミング」を
 教える場合、何を理解してほしいと思いますか?
 また、そのために、どのような手法・例題を用いますか?
 ※高価な社外研修などは予算的にムリです(^^
 
【初心者の方へ】
 オブジェクト指向プログラミングと、
 構造化プログラミングの違いって分かりますか?
 (どのように理解していますか?)
 

20

回答

3028

閲覧

20件の回答

評価

0

手法と言うのか分からないけど、「オブジェクト」なんて言うから分からないのかもしれない。
「何をするか」ではなく、「主人公や脇役は誰か」を考えてみるというか。
「手続き」ではなく「モノ」を先に考えられるようになるかだと思う。

研修なんてマチマチだし、いいも悪いもない。たった一言で考え方がガラッと変わることだってあるんで、研修が必要だと言うわけじゃない。

評価

0

本当に必要なのは「OOP」の知識?
「OOA」や「OOD」の知識ではなくて?

オブジェクト指向=オブジェクト指向プログラミング

じゃないでしょう。
何を教えたいのか、もう一度考えたほうがいいのでは。

評価

0

To:$さん

>たった一言で考え方がガラッと変わることだってあるんで、
>研修が必要だと言うわけじゃない。

→実際に、こういうキッカケを与えてあげられた「一言」ってあります?
そんなメタファなどがあれば知りたいと思って投稿しました。


To:Kさん
>本当に必要なのは「OOP」の知識?
>「OOA」や「OOD」の知識ではなくて?

→OOPと、OODへ繋がる考え方・知識です。
実際には、1年目で入門書ベースの構文を学習し、多少の実務経験を経て、2年目でGof本ベースでデザインパターンやUMLの学習を行う予定でした。

>何を教えたいのか、もう一度考えたほうがいいのでは。

→ごもっとものご指摘だと思います。
上記、1年目研修で、構文を重視しすぎたせいか、2年目研修では、Gof本の解説を見ても、ほとんど理解出来なかったようです。
基本習得→設計入門に入るにあたり、何が足らないのか?何を教えるべきか?に迷っており、投稿した次第です。

実際に、後輩を初級レベルから中級レベルに育てた経験がおありならば、その時に注意・工夫した点などの、経験談を教えて頂けると参考になります。

評価

0

自分の場合だと、「始めにデータありき」だったな。

デザインパターンってのは「オブジェクト指向の集合」とではなく、「設計(ロジック)の集合」なんだよね。
だから、オブジェクト指向を学んだとして、全員がデザインパターンに結びつくか分からない。

恐らく、教えてる人間は皆悩むんだろうな。
やっぱり自分で頭を使って手を動かしていく積み重ねがないと、なかなか分かるものじゃない。
どんどん進む人間もいるけど、そういう人間って変なところでどつぼにはまったりする。

業務のような演習をやるしかないんじゃないのかなあ。
だんだん大きくしていって。
その途中にデザインパターンが入るのは、いいかもしれない。


UMLは個人的にはあんまり重要視してないし、コメントできない。

評価

0

>業務のような演習をやるしかないんじゃないのかなあ。
>だんだん大きくしていって。

→私もこういう形式にしようか迷っているところでした。

うーん、もう少し考えてみます。
ありがとうございました。

評価

0

【初心者の方へ】
 オブジェクト指向プログラミングと、
 構造化プログラミングの違いって分かりますか?

私はjavaから入ったので、
構造化プログラミングを良く知らないんですが…

「処理」に重点を置くのが構造化プログラミング。
「処理を誰がするのか」に重点を置くのがオブジェクト指向プログラミング。

違うのかなー。

評価

0

俺はわからない方に入るから、初心者だな。

オブジェクト指向と構造化を対比するのがよくわからん。
オブジェクト指向と手続き型の対比ならわかるんだが。

オブジェクト指向の分野の場合だって、
構造化は当然有効だ。

評価

0

OOPっていったら、
カプセル化、継承、多態性
でしたっけ。

でも、OO=カプセル化、継承、多態性
なんて答えたら、0点ですよね。

評価

0

>・インスタンス(マルチプル)の理解が怪しかったり、
 簡単な処理を実装させると、思いっきり構造化プログラミングに
 なってしまう。

このへんをサンプルコードで示してもらうと、
どう「構造化プログラミングになってる」
のか判って、
どうしたらいいのか具体的な策が出てくる、かも?

評価

0

たくさんのレスありがとうございます。

TO:不良社員さん ------------------------------
>オブジェクト指向と構造化を対比するのがよくわからん。
>オブジェクト指向と手続き型の対比ならわかるんだが。

→java、C言語の対比のつもりで書いています。

>オブジェクト指向の分野の場合だって、
>構造化は当然有効だ。

→そうですね。逆に言うと、javaでもCと全く同じプログラムを書けてしまいます。
研修としては、各自がOOPの適用を工夫したり、OOPの利点を実感出来るような誘導できたらイイなーと考えています。(構造化を否定している訳ではないですよ)

TO:Kさん ------------------------------
>OOPっていったら、
>カプセル化、継承、多態性
>でしたっけ。

→OOPの3大要素ってやつですね!
でも例えばCでもカプセル化って出来なくはないですよね。新人には、言葉の意味だけでなく、これらを適用する事の意味や効果を実感してほしいと感じています。
「何でたくさんクラス作るの?→OOPめんどくさい→仕事で必要だから覚えるか・・」になってしまうと、次のデザインパターンなんて習得しようという気にすらならないんですよね・・


TO:コロさん ---------------------------------
>このへんをサンプルコードで示してもらうと、
>どう「構造化プログラミングになってる」
>のか判って、

→私の書いた物ではないのでソースの転記は控えますが、こんな感じです。
[例]
伝票形式(ヘッダ・明細)のデータをCSVに書き出す。

こちらの意図としては、例えばレコードをクラスと捉えて、ヘッダ・明細用に汎化したり、1:Nのデータの構造や関連を工夫したり、データ構造とI/O処理のクラスを分離したり・・という観点で、自分なりにOOP的な工夫してほしいというものです。
が、結果は1クラス+サブルーチンでFor文・If文をゴリゴリ回すプログラムになってしまうと。

2年目ではデザインパターン研修を行おうと思いましたが、1年目終了時点で、その必要性が実感出来なかったり、インスタンス理解があやふやなのかと感じ、もう一歩手前に「オブジェクト指向基礎」的な研修を設けようと考えている次第です。

評価

0

>結果は1クラス+サブルーチンでFor文・If文をゴリゴリ回す

一番最初に$様が仰っていますが、
>主人公や脇役は誰か
これに尽きるのだと思います。

構造化…は、
仕事をする主体は「プログラマ自身」なのですよね。
でも、オブジェクト指向開発にのっとれば、
鳴くのはプログラマでなく「犬」だったり「猫」だったりするわけで。
○○をしてくれる担当者 を作る
という概念が抜けているんじゃないでしょうか…

以下蛇足

2年目…当方1年半ですが、java(webアプリ全般まで)→C→C++(ついこの間からVC++でwinAPIを触る)といった感じなので、2年目でデザインパターン研修と聞くと…なんとも羨ましいのですが…
あ、でも構造化が根強く残ってる、ってことは、最初はCからなんでしょうかね…

評価

0

>レコードをクラスと捉えて
設計とJavaの知識とは、極端な話関係がない。
設計手法を知っている人間がJavaの構造の有用性に気づくことはあっても、Javaという言語から設計にたどり着くのは難しいと思う。

デザインパターンを「習得しよう」というのも、個人的にはなんとなく違和感を覚える。

UMLのユースケースやシーケンス図を「先に」覚えさせ、書かせるのは有意義かもしれないが…。

評価

0

手続きと同じようにデータも構造化する流れから来てるのがオブジェクト指向プログラミングなわけで、丸っきり区別して考えるのもどうかと思う。

Cでオブジェクティブなコードが書けないわけではないし。

評価

0

最初はみんな物まねから入るものだし。

手続き型でかかれたコードを、オブジェクト指向的なコードに置き換えさせることから始めてはどう?

例えば、

>1クラス+サブルーチンでFor文・If文をゴリゴリ回すプログラム

を最初に提示しておいて、
レコードをいくつかのグループに分類し、
そこから、インターフェースを抽出する。

俺が最初にインターフェースの使い方を覚えたときも、
上記の過程を踏んだと思う。

評価

0

またまた多くのレスをありがとうございます。

TO:コロさん ----------------------------
>鳴くのはプログラマでなく「犬」だったり「猫」だったりするわけで。
○○をしてくれる担当者 を作る

⇒犬・猫のメタファを聞いて、本質を理解出来る人はエライと思います。個人的にはこういうのがキライで、別アプローチで概念を教えようとして、裏目に出ているのかも・・という気がしています。


>あ、でも構造化が根強く残ってる、ってことは、最初はCからなんでしょうかね…

⇒ご想像の通り、構文が似ているという理由で、C→javaの順で一番最初の研修をしています。(逆にそれが原因で、違いがピンと来ないのかも知れませんが)
1〜2年目くらいで、壁を感じたり、これから習得したい知識などを教えて頂けると有難いです。


TO:$さん ---------------------------
>設計とJavaの知識とは、極端な話関係がない。
設計手法を知っている人間がJavaの構造の有用性に気づくことはあっても、Javaという言語から設計にたどり着くのは難しいと思う。

⇒そうですね。
私自身、設計と実装を混在して教えようとしていたのかも知れません。反省します。


不良社員さん -------------------------------------
>手続き型でかかれたコードを、オブジェクト指向的なコードに置き換えさせることから始めてはどう?

⇒リファクタリングってやつですね!
これは「イイかも」と思いました。ありがとうございます。


評価

0

>リファクタリング
・・・なんで、即座にその語が出てこなかったのか。orz
ちくそ。

◆◆悪魔の誘い◆◆

こっちに参戦してみてはいかがですか?
実践の場としては申し分ないかと。
http://www.javaroad.jp/bbs/answer.jsp?q_id=20081120001250101

評価

0

>犬・猫のメタファを聞いて、本質を理解出来る人は

(・´ェ`・) ?
本屋さんを作ってみる。
本クラスを作る。
本には色んな種類がある(辞書・絵本・漫画…
辞書の中にも色々ある(国語辞典・漢和辞典…
・・・・以下永遠に(継承について

私の持っている本はインスタンス。
同じ種類の本はあるけど、コレはひとつ。インスタンス。

本屋さんを作るなら、在庫数はstaticじゃないとダメ

とか…そういう風に学んできたんですが(凄い適当でゴメンナサイ


こういう風に考えないと、
こういうこと(http://www.javaroad.jp/bbs/answer.jsp?q_id=2008061219113789)になりかねないかなと思ってます。

評価

0

TO:不良社員さん ------------------------------
>こっちに参戦してみてはいかがですか?
実践の場としては申し分ないかと。
http://www.javaroad.jp/bbs/answer.jsp?q_id=20081120001250101

⇒実は結構最初の方から参加しているのです。


TO:コロさん ---------------------------------
変なメタファを用いると、知識が限定される恐れがあると考え、構文や言語仕様を重視して教えてきました。
この辺は、メタファの内容に依存すると思いますが、そういう意味で、本屋のメタファはイイかも。(使おうかな・・)

>こういうこと(http://www.javaroad.jp/bbs/answer.jsp?q_id=2008061219113789)になりかねないかなと思ってます。

⇒私はこういう事例を、「ルール」として教え、複雑な継承をした時の動作を、実験によって体感させていました。
なので、うちの新人は、細かい構文的な誤りをする事は少ないのですが、逆に「なぜ」に弱いのかと。

実際のプログラムと懸け離れたメタファを多用するのはキライだったのですが、イメージを掴むために、これらを利用するのは、良い事かも知れませんね。

ありがとうございます。参考になりました。

評価

0

超私的OO論ですが
OOA:意味空間モデル。いわゆる「動物」が「鳴く」とかいうやつ。セマンティックモデル?
OOD:自律分散協調モデル。
OOP:カプセル化、継承、多態性などの「テクニック」

じゃあOOって何?
A-D-Pを貫く統一的なアーキテクチャー=オブジェクトネットワークモデル
がOOのOOたる所以かなあと思ってる。

個人的には、この辺の思想?を理解して欲しいなあ。技術だけじゃなくて。OO技術者には。

評価

0

(1) オブジェクト指向開発プロセスの教育
オブジェクト仕様は要件定義レベルから適用されるため、分析手法、設計手法などを学んでください。
Unified Process/RUP、アジャイルプロセスなどが参考になります。
これによって顧客要件を元に効果的なオブジェクト設計をできる人材を育成できます。
また、UML は本来これらのプロセスで使用されることを前提としています。
これらは市販の書籍があります。
(2) デザインパターン、アーキテクチャパターンなどを学んでください。
オブジェクトの組み合わせ方法の定石やノウハウを学べます。
これらは市販の書籍があります。
(3) デファクトスタンダード指向
Java API のソースや C# のソースを読んで、一般的な開発手法を
身に着けてください。我流では大規模/国際的なプロジェクトに
対応できません。
これはとにかく数をこなすしかありません。
先輩とペアプログラミングしたり、コードレビューしてもらうと成長スピードが大幅に向上します。

質問から6ヶ月以上経過しているので、回答を書き込むことはできません。