- ベストアンサー
オブジェクト指向全般、クラス設計についての質問です
- 質問者はオブジェクト指向について深く学びたいと考えているが、現状では理解が十分でない。
- 特にどのクラスを作成すべきか、オブジェクトの関連性に関して戸惑っている。
- 質問者はアドバイスやおすすめの書籍を求めている。
- Simula777
- お礼率100% (3/3)
- その他（プログラミング・開発）
- 回答数3
- ありがとう数3
- みんなの回答 （3）
- 専門家の回答
質問者が選んだベストアンサー
私も質問者さんと同じように、原則だの設計手法だのに振り回されてコードが書けなくなった経験があります。今でもたまに手が止まってしまいます。 ＞ちょうど作文の最初の一文が見つから無いときのような、そんな感覚に襲われてしまします。 というのは痛いほどよくわかります。 作文で手が止まってしまうのは、そもそも文章を書き慣れていないと、どうすれば相手に自分の考えが伝わるのか、それ以前に自分が何を伝えたいのかもわからない、読んだ相手がどう思うのか想像出来ないからではないでしょうか。「何を求められているのか」という判断基準そのものが無いが故に手の付け方もわからない状態です。 ソフトウェアの設計も似たようなもので、どんな機能が必要で、どんな問題が起こりうるのか、何処が頻繁に変更され、どんなコードなら自分や他人が把握しやすく、保守しやすいか、みたいなのは、最初のうちは見当つかないものです。熟考すれば出てくるものでもありません。 知識をつけると、最初は問題ではないものまで問題に見えてきます。 そうした段階で分析を行っても、書いていてモヤモヤする、何となく気持ち悪い、違和感がある、みたいな理由しかでてきません。しかし、それは本当に取り組むべき問題ではありません。 実作業に支障を来していないコードを、問題に仕立て上げようとしているだけです。 経験豊富なプログラマなら納得出来る理由を説明し、より良い解決策を提示して設計を見直すかもしれません。 しかし、改善すべき明確な理由も方向性も見えていないのなら、手のつけようがありません。 恐らく何処まで経験を積んでもそういう霧は晴れません。そもそも何が必要になるか、何が問題になるのか、みたいな予知を完全に行うことはできないからです。常に不安はつきまといますし、想定外の仕様変更なんていくらでも出てきます。具体的な形になって使い方が解ると、新たな使い道が見える事も少なくありません。そうしてソフトウェアは進化していっています。 拭いきれない違和感との戦いは終わりがないのも問題です。これこれを達成すればひとまずOKという基準を作るのも設計の一環です。 ならば、真っ先に取り組むべき問題は、書いていてイライラする、実作業に支障が出ているところです。 ある機能を呼び出すのに長～いコード何度も書かなければならなかったり、機能を追加するたびにプロジェクト中の修正を必要としたり、一見関係ないコードを修正すると頻繁にバグったり…。 私が今のところこういう状態に陥ったとき、一番巧くやれている方法は、本やネットで得た知識は一旦シャットアウトして、形にする。そして実際に使い続けてみる。また、複数の方法で作ってみて比較する、です。 そうして問題点を洗い出し、再設計を行います。 これを何度も繰り返します。 いわゆるスパイラルモデルというやつですが、「想定される問題」ではなく、プロトタイピングで「顕在化された問題」に対して取り組むのが重要だというのが私の現在の結論です。勘のきかない経験の少ないコードほどそう感じます。逆に何度も組んだことがあるコードは、繰り返し回数が減り、結果的にウォーターフォールになります。 あるオブジェクトを何処が持つべきか、見当がつかなければ、とりあえずグローバルな場所に置いておきます。 C#ならシングルトンとして作ってクラスメソッドで取得させるとか、メインフォームに置いとくとかです。 作り込んでいくうちに、全く関与しないクラス、殆ど全ての機能からアクセスされるオブジェクトなど、関連性はある程度明確になりますし、グローバルにアクセス出来るオブジェクトの問題点もそのうち直面します。 そのとき、再び本を開いてみてください。書いてある意味がまるで違うことに気がつきます。それを何回も何回も繰り返して、ようやく理解したことになるんだと思います。 だらだらとした長文で「結局経験っすよー」みたいな話ばかりで申し訳ありません。 ですが、少しでも切っ掛けが掴めれば幸いです 参考URLは私が以前した、似たような質問のURLです。ご参考までに。
その他の回答 (2)
- lv4u
- ベストアンサー率27% (1862/6715)
No.1です。 他に回答が付かないようですので、追加で回答してみます。 >>その中でも、特に戸惑ってしまうのが、「何をクラスにするのか」という最も基本的な部分です。 まずは、Ｃ＃が手本としたＣ＋＋、そしてＣ＋＋の前身である C with Classesが生まれた背景には、「複雑で巨大なソフトウエア開発を行う」という目的がありました。 ですので、"Hello, World!”を１行表示するプログラムのように短くてシンプルなプログラムでは、クラスなんてものの出る幕はありません。 そして、2ch用ブラウザのコードは、それよりもコードは大きく、複雑になると思いますが、まずはオブジェクト指向以前の、構造化プログラミングや複合設計の考え方でデータ構造やモジュール構成、どんな処理が必要か？などを洗い出すところから始めたらいいように思います。 それらの考え方・分析手法を行えば、「責務」「単一責任の原則」「高凝集度」「疎結合」等を考慮したモジュール設計（モジュール分割）ができると思います。 それらのモジュール群とデータ構造で関連の深いものをまとめてクラスにすれば、第一段階のクラス設計ができるように思います。 ここから、さらにポリモーフィズムや継承など、オブジェクト志向からの考え方を取り入れて、さらにクラスを洗練すれば、いいのではないかと思います。 なお、継承は多用すると、共通結合的な弱さがプログラムに持ち込まれるので、できれば使わないほうがいいかもしれませんね。 （昔、継承を使いまくったプロジェクトがあり、開発メンバーの皆が苦しみました・・・） >>個々のオブジェクトの関連において、あるオブジェクトを保持するのはどのオブジェクトであるべきか？ >>また、あるオブジェクトにメッセージパッシングするのはどのオブジェクトであるべきなのか？ オブジェクト指向の書籍では、しばしば「オブジェクトにメッセージパッシング」という表現を使っていますが、Ｃ＋＋やＣ＃では、構文としては、関数呼び出しの変形です。 なので、モジュール呼び出しの親子関係やデータ管理責任はどこが持つべきか？と考えれば、「あるオブジェクトを保持するのは、どのオブジェクトであるべきか？」の答えは自然に決まると思います。 そして、これらの構造化／複合設計の知識があって、初めてクラス設計ができるのだと私は思っています。 ちなみに2ch用ブラウザといった通信系のプログラムは、オブジェクト指向でアプローチするのもいいのですが、その前に、状態遷移図、ステートマシンの考え方で設計するほうがロジックがすっきりすると思います。 構造化／複合設計の参考図書としては以下のものをあげておきます。 ・ソフトウエアの複合／構造化設計－／マイヤーズ（１９７６年発行の本で古いのですけど、今でも十分に通用する内容だと思います。） ・ソフトウエアの信頼性－ソフトウエア・エンジニアリング概説／マイヤーズ （発行 １９７７年） ・ソフトウエア作法／Brian W.Kernighan、P.J.Plauger（１９８１年）
お礼
参考になります。 OOPが決してある日突然誕生した新しい概念ではなく、連綿と続くソフトウェア技術の進化の形であって 必然的に生まれたものである。 というのは、前に挙げた書籍の文言ですが、真にこの意味を理解できてないように思います。 ・・・と、十数年前に買ったC言語の、日焼けして黄色くなったテキストをめくりながら感じました。
- lv4u
- ベストアンサー率27% (1862/6715)
質問者さんの質問への正面からの回答ではないのですが・・・ >>その中でも、特に戸惑ってしまうのが、「何をクラスにするのか」という最も基本的な部分です。 その疑問は私の読んだＣ＋＋の本にも書かれていました。私は「ケースバイケースで、問題を分析して、それで決まる」なんて思っていました。 ただ、最近は、その疑問よりも前に、「クラスを作って、あるいはオブジェクト指向で開発効率はアップするのか？」というもっと基本的な疑問がくるべきでは？なんて思っています。 つまりクラスとかオブジェクト指向って、それらの最終目的は、開発工数の削減とバグを無くすことだと思います。 それは、住宅建設に例えるなら、注文主（施主）の希望に合わせた小さな部材で組み上げる注文住宅（ミスが発生しやすい）より、大きな単位の規格パーツの組み合わせで完成するプレハブ住宅のような、短納期で確実な仕上がりになる方向に向かうのと似ているように思います。 「責務」「単一責任の原則」「高凝集度」「疎結合」などの原則があるのはわかりますけど、先ほどの建築の事例で例えれば、「ノミやカンナの上手い使い方」「ノコで直線に合わせて板を切断するコツ十則」なんてものに相当するのかな？なんて思います。 現在の建築現場では、電動ドライバー、電動丸ノコなど、いろんな電動工具類が作業効率を飛躍的にアップさせています。電動工具で作業する人にとっては、そんな昔ながらの道具の使い方原則は「古いよ！それより新しい電動工具の使い方のノウハウを教えてくれ！」っていうことになりそうです。 上記のような考え方は、Ｃ＃のバージョン３．５や４．０について記載された本を読んだときに、「クラスは単なる入れ物にすぎない」「新しく導入されたラムダ式は、クラスの原則を壊すもの」「動的プログラミング」なんて記述があり、「目から鱗」と感じたからです。 質問者さんは、幸いＣ＋＋やＪａｖａでなく、Ｃ＃を選ばれていますから、Ｃ＃ ３．５以降のそんな機能を大いに教授できると思います。 お勧め本は、川俣 晶さんが書かれた「究極のＣ＃プログラミング～新スタイルによる実践的コーディング」「Ｃ＃実践ダイナミックプログラミング」「Ｃ＃ショートコードプログラミング」などです。
お礼
たしかに、手段が目的になってはいけない・・・と最近感じてます。 おすすめしていただいた書籍についは、機会があったら読んで見たいと思います。
お礼
参考になります。 回答者さんの以前にされた質問も読ませていただきましたが まさに今の自分と同じです。 >ＯＯＰは手段であって目的ではありません。 耳が痛いです。 というやりとりは、自分もホントに耳が痛いです（笑） そしてまた そうした段階で分析を行っても、書いていてモヤモヤする、何となく気持ち悪い、違和感がある、みたいな理由しかでてきません。しかし、それは本当に取り組むべき問題ではありません。 実作業に支障を来していないコードを、問題に仕立て上げようとしているだけです。 という部分もマコトに仰る通りです。 霧はまだ晴れてはいませんが、霧の中にいる自分をはっきり見ることはできるようになった気がします。