オブジェクト指向(具体的にはどんなクラスで作ります?)

　オブジェクト指向、クラスの便利さは大体わかりました。
（赤外線やマイクロ波の専門的な説明はわかったけど、リモコンや電子レンジに具体的に見てみないと、ぴんときていない状態だと、思います。）
それに、一人で作っていることもあり、また構造化プログラミングで今まで作ってきたので、具体的にどういうクラスに分け、どういうことを将来予想し、作るのかがわかりません。

仮に、シンプルな日記から作る場合、どういったクラスを作り、どういうことを予想し、作りますか？
特に、継承や他に使いまわせるようにとか、ソフトを作り、何を想定するのかを知りたいです。

No.1 回答者： MrBan 回答日時： 2006/08/20 02:03

えっと、本クラスに集約されたページクラスがあって…

とかそういうことを決めるのは後の話なので、
最初はユースケースとかで「シンプルな日記」というものの使い方や機能などをある程度決めます。
これをベースにして、これに対する機能変更や保守を想定したり、流用製を考慮したりするのであって、それを定義せずにどんなクラスを作りますか、と聞くのは難しいと思いますが。
# 目的があっての設計/方法論なので。

で、ご質問の件は設計/分析上の用語としては「クラス抽出」と呼ばれると思いますので、これで検索してみてください。
名前/名詞抽出とかいろいろな方法論が見つかると思います。

入門用で、最近私がわかり易いと思って進めている本を参考に載せておきますので、ご興味があれば本屋さんなどでご覧になってみてはいかがでしょう。
言語としては一応組み込み系のC++が想定されてますが、本質はモデリング～製造～評価まで一通りを舐めている本なので他言語でも考え方は使えると思います。
理論に走るというよりは、構造化とかで経験もあり基礎はわかっているような人がオブジェクト指向で作ってみる場合の入門指南書だと思ってます。

参考URL：http://www.amazon.co.jp/gp/product/4798111767/25 …

この回答への補足

目的は、質問者様の方である程度決めていただいて結構です。
なので、合えて言及しませんでした。
「自作で日記を作るとしたら。」と置き換えていただいてもかまいません。
プログラム全部を書いてほしいのではなく、クラスのイメージがわかる青写真の段階で問題ありません。

補足日時：2006/08/20 07:35

この回答へのお礼

クラス抽出で検索してみようと思います。
実際の場面で、クラス抽出のお手本を見ていないので、どう言うクラス抽出がいいのかが、ぴんときていない状態です。
ありがとうございます。

お礼日時：2006/08/20 07:53

No.2 回答者： dekopa- 回答日時： 2006/08/20 10:44

UCとして「日記を読む」「日記を書く」だけと仮定して。

この場合「日記(dialy)」と「読み書きする人(person)」でしょうか。「誰が」がクラスになるかどうかはシステム次第ですが、ユーザー登録があると仮定して。
日記のメソッドとして「読む」「書く」ですね。

他にどんなメソッドが必要かは、ユースケース次第です。あるいはUCに追記されたシナリオにどういう記述があるか、ですね。
UCで想定されていないなら書きません。「足りないかな？」と思ったら、まずUC側を修正し、クラスに追記します。
日毎に分けるために「ページ」があり、「タイトル」「本文」があり、おまけで「天気」「気温」「絵日記の絵」があるかもしれません。

詳細レベルになると、今度は実装する言語のライブラリやフレームワークが強く影響します。
継承や再利用などは、現在はフレームワークとの兼ね合いを考えるのが主です。日記を読む、書くといったクラスなら、StreamクラスやReader/Writerクラスが必ずありますし、データベースに保存する場合はそれ用のクラスがあります。

入門書の継承の例は自分で作ったクラスを自分で継承するパターンが大半ですが、それは概念を教えるためのもので、現実にはフレームワークをうまく再利用する事が大事です。

この回答へのお礼

とりあえず、日記については自作すると見なしてください。
入門書は、映画のように必要な物がすでに決まっていて、できレースな一面もあるので、いざ自分で作ろうとするとなにがなにやら分からなくなっています。
しかも、レンガの積み方を教えただけで、後はその応用なのでお城を造りましょう。と言われても。
せめて家の作り方くらいの中級者のソフトの作り方の指南書があればいいのです。
今は雛形を使う際に、それに不都合な場合、継承するという一面もあるんですか。
わりと完璧主義者の面もあるので、全て自分で作りたいと思ってしまうので、自分で作ったものを再利用する事に視点が言ってしまい大局をみていなかったのかもしれません。

お礼日時：2006/08/22 23:00

No.3 回答者： MrBan 回答日時： 2006/08/21 15:01

# 基本的には#2の方の回答に同意。

私の想定だと、
[人] (1) --- (N) [日記] (1) ◆--- (N) [頁]
くらいは作ることになりそうな気がしますが、
そうすると、頁には「書く」「読む」とか、
日記には「頁をめくる」とか「この頁に書く」「この頁を読む」とか？

# UC次第では「鍵をかける」とか「破り捨てる」とか？

こいつらをどう動かすかの部分は、UCやフレームワークへの依存度が大きくなりますね。

この回答へのお礼

やはりフレームワーク、過去の資源の有効利用ですか。
ＰＨＰのライブラリーはよく見かけましたが、他の言語の雛形を探したことがないので知りませんでした。

それでも、
一つは、全部自分で作りたい。
一つは、雛形には自分８の必要としない部分もあり、処理や負荷が大きくなるのでは？という不安。
（最近のＰＣは優秀なので、気にしなくてもいいとは思うのですが。
一つは、資源を使うことが勉強につながるのか？
一つは、探したことがないので、探し方がわからない。（それは自分でも調べますが。

おそらく、個人でのんびりとフリーソフトを作るか、納期を優先させている専門家によって、考え方も少し違ってくるとは思いますが。

お礼日時：2006/08/22 23:09

No.4 ベストアンサー 回答者： suzume00#2 回答日時： 2006/08/21 19:27

あんまり参考にならないかもしれませんが。

１人で自由にコーディングしているのであれば、まずどんどんソースを書いていって「何か似たようなコード書くことになるな」「同じコード書くことになるな」という段階で、クラス化します（まぁ最低限、最初の段階でReadクラスとWriteクラスと分けますが）。

仕事で客先からの要求がある場合は、あらかじめコーディング前に、「似たようなコード書くことになるな」「同じコード書くことになるな」を想定して、クラス化します。

余裕があれば、「この要件は、後々同じようなことを言ってくるだろうな」というのも、クラス化しておきます。が、「一歩先を見越す」程度でそれ以上はしません（限られた納期ですし、アテが外れる場合もありますから）。

それと、保守しやすい・見やすい（結果としてバグが出にくくなる）という点もクラス・メソッド設計では重視します（今、他人が作ったソースの保守・改修で泣きを見ているので）。

うーん、あまりレベルは高くないかもしれませんが（涙）、今の私の現状です。

この回答へのお礼

delphiなので完全にクラス化しなくてもいいので、構造化で書いていっています。
一部クラス化もさせましたがまだ小さなソフトなため、継承等のオブジェクト指向を意識した書き方ではありません。
サブルーチンとあまり変わらないし、クラス化させるとメモリーから解放させないとまずいので、それが少し怖いです。
だったら、サブルーチンでもいいので、戻そうかどうか迷っています。
特にクラス化させなくてもif文で条件分岐させれば、オーバーロードっぽい事もできますし。
オブジェクト指向は、やはり大勢で大規模なソフトを作成する場合に、効果を発揮するものなんんですかねー。

お礼日時：2006/08/22 23:26

No.5 回答者： MrBan 回答日時： 2006/08/22 23:37

モデルに関しては、過去の資源がないならないで新規でもいいと思います。

あれば使う。特に勉強主眼ならば無理に探してまで流用する必要はないんじゃないでしょうか。

> こいつらをどう動かすかの部分は、
> UCやフレームワークへの依存度が大きくなりますね。

UC(Use Case)はご自身で決めるでしょうし、これを実現するための設計ですから当然依存します。
「始めに目的ありき」なのは最初から書いてる通りです。

で、UIとかビューの部分は、どうしてもライブラリなりフレームワークなりに依存してきますから、これなしにクラス構成を決めてもあまり意味がないです。
# 画面設計とかは依存しないと思いますが。

この回答へのお礼

やはり、そのときの場合に依存する場合が大きいと言うことですね。
ありがとうございます。

お礼日時：2006/08/31 15:23