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

趣味でプログラミングをしているのですが
オブジェクト指向の概念がうまく理解できていないので
教えていただけませんでしょうか？

解説本などを読むと、オブジェクト指向のクラスを動物クラスを継承して犬クラスや猫クラスなどと解説してあるのですが。
どうも、僕がプログラム設計するとしっぽクラスや泣き声クラスなどといった違った動物の類似機能をまとめてのクラスをつくり各メソッドとしてしまいまっています。

動物クラスや乗り物クラスを組み合わせてプログラムを設計する事ができません。

本格的なプログラムを組む用途では無いので気にしなくても目的の機能が実装できれば問題無いと知人からは言われ(面倒なので教えたくないのかもしれませんが)そのまま来てしまいました。

最近、気になって来たので。

正しい使い方を身に着けたいと思いチャレンジしていますが、変な癖がついていて犬や猫クラスなどと思いながら設計していると思考が止まってしまいます。

そこで、下記のことを教えていただけませんでしょうか？

(1)泣き声クラスなどの同機能を１つのクラスにしてしまう設計しか出来ない(発想できない)のは考え方のどこがわるいのでしょうか？

(追記：一部分だけならペンギンクラス猫クラスなどと言う動物クラスの継承的な発想はできるのですが実際のプログラミングの際は動物のようなわかり易い物オブジェクトとして目に見える物体ではない事柄をオブジェクト化にする事が難しく感じるのではないかと思います。)

(2)今までの小さい規模での開発なら、クラスのつくり方がおかしくても不具合は無かったのですが、どのような時に困る事があるのでしょうか？(解説などでも再利用性などと、さらっと解説されていますがイマイチぴんときません)

(3)正しくオブジェクト指向がマスター出来ている方にとって、どのクラスにどのメソッド実装するか悩む事などはあるのでしょうか？
また、設計で一番悩むのはどのあたりですか？

(4)UMLのマスターは必須でしょうか？(現在は、なんとなくUMLぽい感じでメモ書きをつくり、えせオブジェクト指向でプログラムを組んでいます。)

(5)その他アドバイスがあればお願いします。

※乱文で問題もハッキリせず質問の整理等がうまくいっていないと思いますが１つの項目だけでも構いませんので、ご教授お願いします。

No.5 ベストアンサー 回答者： choconamacream 回答日時： 2008/10/25 20:20

(1)泣き声クラスなどの同機能を１つのクラスにしてしまう設計しか出来ない(発想できない)のは考え方のどこがわるいのでしょうか？

仕様が明確になっていないからだと思います。それと、デザインパターン（GoFパターン）やJ2EEパターンを一通り理解しておくことをおすすめします。必ずしも、デザインパターンを適用する必要は無いかと思いますが、知識として自分の頭の中に入れておくことは非常に有効です。

(2)今までの小さい規模での開発なら、クラスのつくり方がおかしくても不具合は無かったのですが、どのような時に困る事があるのでしょうか？(解説などでも再利用性などと、さらっと解説されていますがイマイチぴんときません)

・機能拡張しようとする時
→クラスをきちんと分けずに冗長的なコードになっていると、また同じコードを打つこととなります。きちんとクラス間のつながりがしっかりしていれば、後は既存のインタフェースや抽象クラスなどを再利用して、新機能の部分のみを追加するだけで済みますから。

・保守をする時
→ちゃんとクラスに分けられていないと、ある部分を修正したとしても、それが他のコードに悪影響を及ぼすことになるかもしれません。いわゆる、デグレードとかレグレッションテストとかの類ですね。クラスが詳細に分けられていれば、あるクラスに変更を入れたとしてもそれが他のクラスに影響するのを必要最小限に抑えることが可能となりますし、テストの際にもその変更を入れた部分のみを実施すればいいということになりますね。

(3)正しくオブジェクト指向がマスター出来ている方にとって、どのクラスにどのメソッド実装するか悩む事などはあるのでしょうか？
また、設計で一番悩むのはどのあたりですか？

(1)と同じく、ゴールが決まっていないと、結局はいつまで経っても右往左往してしまいます。オブジェクト指向開発というのは以下のような一連の流れになっている為、必然的に前の工程が手抜きをしていると次の工程がもろにその影響を受けてしまいます。

要求定義→オブジェクト指向分析→オブジェクト指向設計→オブジェクト指向プログラミング→テスト

(4)UMLのマスターは必須でしょうか？(現在は、なんとなくUMLぽい感じでメモ書きをつくり、えせオブジェクト指向でプログラムを組んでいます。)

必ずしも必須ではありませんが、SJC-WCの本なんかでは何の説明もなくいきなり「クラス図」や「シーケンス図」が出てきますし、ソフトウェア開発技術者の試験でも「ユースケース図」や「シナリオ」に「ステートマシン図」などの問題が出てきたりします。その辺に関しては、理解しておいて損は無いと思います。

(5)その他アドバイスがあればお願いします。

本を２、３冊読んだぐらいで理解しようとは思わないでください。私自身、４、５冊目あたりくらいかなあ、と。オブジェクト指向関係の書籍に何冊も目を通すうちに次第と知識も深まってきて、既存の知識の所ではより理解が深まり、自然とモノの考え方が出来上がっていることでしょう。

参考URL：http://oshiete1.goo.ne.jp/qa4167313.html

この回答へのお礼

ありがとうございます。
どうしても、趣味でのプログラミングのため、ゴールや方向感の乏しいボトムアップ型の思いつき実装作業が中心になっていましたのでその辺にも原因があったように思えます。
オブジェクト指向の一番初めにUMLとデザインパターンを勉強してみました。おっしゃる通り１、２冊くらいの本で理解できずに実践でなんとかなるだろうと思ってたらいつの間にか悪い癖がついていたので質問をださせて頂いたのですが。
やはり、必要なUMLを作りデザインパターンを意識しながら解らない所を学習すると言う方法がよさそうですね。
きめ細やかなアドバイスや参考URLにも大変感謝しております。

お礼日時：2008/10/26 00:35

No.4 回答者： thamansa 回答日時： 2008/10/20 22:35

(3)

どのクラスにどのメソッド実装するか悩む事はあまりありません。
なぜなら悩むケースは、どちらも一長一短だったりすので、とりあえずどちらかのクラスに実装してしまい、あとで変更したくなったらリファクタリングするだけです。
設計で悩むというか一番考えるのは、あまり「オブジェクト指向的に正しい設計」を目指すと、必要以上に複雑になってしまうので（必要以上に複雑なのは悪い設計です）、ある程度は「手続き指向的な設計」にします。そのバランスをとるところを一番意識して設計します。
（本当に悩ましいのは、上記の設計を理解してもらえないこと・・・）

この回答へのお礼

>ある程度は「手続き指向的な設計」
なるほど、良くわかりました。
オブジェクト指向的に正しい設計を目指さずに効率よくシンプルに書ける事を目指せば良い感じですね。
中途半端な応用はその先の問題をこじらせそうなので臆病になり避けていましたが、
躊躇していても先に進めそうも無いので参考にさせていただきます。

お礼日時：2008/10/22 23:28

No.3 回答者： snowize 回答日時： 2008/10/18 09:48

ほんと「動物クラス」で説明して分かるかって話ですねｗ

(1) 説明が悪いだけなので気にしないで構いません。適切な理解が得られれば必然的に解決されます。
(2) 個人で趣味で作る範囲では問題ありません。オブジェクト指向をうまく利用できると開発が楽になるというだけですので。
(3) コツがつかめてくると悩むことは少なくなってきますが、まったく新しい分野に手を出すと「何をオブジェクトにしようか」少しとまどうかもしれません。自分が実務より設計にこだわっちゃうマニアだからかもしれませんが。
(4) 個人で趣味で作る範囲ではやっぱり問題ありません。ただし概念を理解して自分なりの記法を決めておくのはいいことだと思います。
(5) 自分が最初にお世話になった本は『憂鬱なプログラマのためのオブジェクト指向入門』です。

この回答へのお礼

>「何をオブジェクトにしようか」少しとまどうかもしれません。
このような試行錯誤は専門家の方でもあるのですね。
どうも自分の理解力ではオブジェクト指向言語などの複雑な概念のあるものに手を出すのは危険かななんて考えていたので少しほっとしました。もう少し努力してみようと思います。

お礼日時：2008/10/18 10:51

No.2 回答者： buriburi3 回答日時： 2008/10/18 05:42

オブジェクト指向プログラミング(オブジェクト指向デザインではない)が何の為に発明されたかが理解できていない事が原因では無いかと思います。

「犬がワンで猫がニャー」のありがちな(そして、大抵の場合オブジェクト思考プログラムとオブジェクト指向デザインがごっちゃになって語られるピントはずれな)概念説明を真に受けても理解は不可能です。

ぶっちゃけ、オブジェクト指向プログラムは手抜きの為に存在します。
※プログラムの可搬性、流用性と言い換えると響きが良いですが。
後で機能を追加・変更したり、以前作ったコードや人が書いたコードを利用する場合にコードの詳細を解析しなくても使えるようにする事が目的です。
※大抵、時間がたつと作った本人も詳細を忘れるから《人が書いたコード》と統一してもあながち間違いではない。

以上をふまえて
(1) 現状で機能をまとめるのではなく、使いまわせるコードと使いまわしの効かないコード、変える可能性が高いコードと変える可能性が低いコードに分けて考える。

(2) 使い回しが効かない、改造・拡張が難しいのではオブジェクト指向プログラミングの所期の目的を果たしておらず構造化プログラミングと変わらない。

(3) 常に悩むしやり直す事もある、そのために《リファクタリング》と言う技術もある。

(4) 必要無い。けど、クラス図位は画けた方が良い。

(5) 技術以前の意義と概念が良く分かる
　『オブジェクト指向でなぜ作るのか』出版社: 日経BP社 (2004/6/3) 　ISBN-10: 4822281957
　を読むことをお勧めします。
　

この回答へのお礼

>何の為に発明されたかが理解できていない事が原因では無いかと思います。
根本を見失っていました。
初めはオブジェクト指向は便利そうだと言う発想で手を出しました。
今では、同じような関数が全体に紛れ込まないようにと整理の意味だけでクラス別けしていたわけで、オブジェクト同士の連携の意味など考える事を忘れていました。ありがとうございますおかげで問題解決まで一歩進めたようです。

お礼日時：2008/10/18 11:10

No.1 回答者： koko_u_ 回答日時： 2008/10/18 01:12

>動物クラスや乗り物クラスを組み合わせてプログラムを設計する事ができません。

例が悪すぎます。普通は動物クラスなど考えないからね。

>犬や猫クラスなどと思いながら設計していると思考が止まってしまいます。
犬クラスや猫クラスも普通考えないからね。思考も止まるさ。


今目の前にあるソースコードでオブジェクトが何かを考えるべきです。
まずは Java が用意している標準のクラスの動作を把握することから始めてはどうでしょう。

この回答へのお礼

今は、既存のソースコードからオブジェクトが何かを考えられないので(思いつかない)他の方が作ったクラスの動作を把握すると言うのを試してみようと思います。

お礼日時：2008/10/18 11:44