>オブジェクト指向(具体的にはどんなクラスで作ります?)入力中の回答があります。ページを離れますか?※ページを離れると、回答が消えてしまいますページを離れるA回答を続ける入力中のお礼があります。23:13回答数:5件オブジェクト指向、クラスの便利さは大体わかりました。(赤外線やマイクロ波の専門的な説明はわかったけど、リモコンや電子レンジに具体的に見てみないと、ぴんときていない状態だと、思います。)それに、一人で作っていることもあり、また構造化プログラミングで今まで作ってきたので、具体的にどういうクラスに分け、どういうことを将来予想し、作るのかがわかりません。仮に、シンプルな日記から作る場合、どういったクラスを作り、どういうことを予想し、作りますか?特に、継承や他に使いまわせるようにとか、ソフトを作り、何を想定するのかを知りたいです。通報するこの質問への回答は締め切られました。フレームワーク」に関するQ&A:概念フレームワークに出てくる用語の意味について。19:27あんまり参考にならないかもしれませんが。1人で自由にコーディングしているのであれば、まずどんどんソースを書いていって「何か似たようなコード書くことになるな」「同じコード書くことになるな」という段階で、クラス化します(まぁ最低限、最初の段階でReadクラスとWriteクラスと分けますが)。仕事で客先からの要求がある場合は、あらかじめコーディング前に、「似たようなコード書くことになるな」「同じコード書くことになるな」を想定して、クラス化します。余裕があれば、「この要件は、後々同じようなことを言ってくるだろうな」というのも、クラス化しておきます。「一歩先を見越す」程度でそれ以上はしません(限られた納期ですし、アテが外れる場合もありますから)。それと、保守しやすい・見やすい(結果としてバグが出にくくなる)という点もクラス・メソッド設計では重視します(今、他人が作ったソースの保守・改修で泣きを見ているので)。うーん、あまりレベルは高くないかもしれませんが(涙)、今の私の現状です。通報するこの回答へのお礼delphiなので完全にクラス化しなくてもいいので、構造化で書いていっています。一部クラス化もさせましたがまだ小さなソフトなため、継承等のオブジェクト指向を意識した書き方ではありません。サブルーチンとあまり変わらないし、クラス化させるとメモリーから解放させないとまずいので、それが少し怖いです。サブルーチンでもいいので、戻そうかどうか迷っています。クラス化させなくてもif文で条件分岐させれば、オーバーロードっぽい事もできますし。オブジェクト指向は、やはり大勢で大規模なソフトを作成する場合に、効果を発揮するものなんんですかねー。23:37モデルに関しては、過去の資源がないならないで新規でもいいと思います。勉強主眼ならば無理に探してまで流用する必要はないんじゃないでしょうか。UCやフレームワークへの依存度が大きくなりますね。Case)はご自身で決めるでしょうし、これを実現するための設計ですから当然依存します。「始めに目的ありき」なのは最初から書いてる通りです。UIとかビューの部分は、どうしてもライブラリなりフレームワークなりに依存してきますから、これなしにクラス構成を決めてもあまり意味がないです。画面設計とかは依存しないと思いますが。通報するこの回答へのお礼やはり、そのときの場合に依存する場合が大きいと言うことですね。ありがとうございます。基本的には#2の方の回答に同意。UC次第では「鍵をかける」とか「破り捨てる」とか?こいつらをどう動かすかの部分は、UCやフレームワークへの依存度が大きくなりますね。通報するこの回答へのお礼やはりフレームワーク、過去の資源の有効利用ですか。PHPのライブラリーはよく見かけましたが、他の言語の雛形を探したことがないので知りませんでした。一つは、全部自分で作りたい。一つは、雛形には自分8の必要としない部分もあり、処理や負荷が大きくなるのでは?という不安。(最近のPCは優秀なので、気にしなくてもいいとは思うのですが。一つは、資源を使うことが勉強につながるのか?一つは、探したことがないので、探し方がわからない。(それは自分でも調べますが。個人でのんびりとフリーソフトを作るか、納期を優先させている専門家によって、考え方も少し違ってくるとは思いますが。10:44UCとして「日記を読む」「日記を書く」だけと仮定して。この場合「日記(dialy)」と「読み書きする人(person)」でしょうか。「誰が」がクラスになるかどうかはシステム次第ですが、ユーザー登録があると仮定して。日記のメソッドとして「読む」「書く」ですね。他にどんなメソッドが必要かは、ユースケース次第です。UCに追記されたシナリオにどういう記述があるか、ですね。UCで想定されていないなら書きません。「足りないかな?」と思ったら、まずUC側を修正し、クラスに追記します。絵」があるかもしれません。詳細レベルになると、今度は実装する言語のライブラリやフレームワークが強く影響します。継承や再利用などは、現在はフレームワークとの兼ね合いを考えるのが主です。日記を読む、書くといったクラスなら、StreamクラスやReader/Writerクラスが必ずありますし、データベースに保存する場合はそれ用のクラスがあります。入門書の継承の例は自分で作ったクラスを自分で継承するパターンが大半ですが、それは概念を教えるためのもので、現実にはフレームワークをうまく再利用する事が大事です。通報するこの回答へのお礼とりあえず、日記については自作すると見なしてください。入門書は、映画のように必要な物がすでに決まっていて、できレースな一面もあるので、いざ自分で作ろうとするとなにがなにやら分からなくなっています。レンガの積み方を教えただけで、後はその応用なのでお城を造りましょう。家の作り方くらいの中級者のソフトの作り方の指南書があればいいのです。今は雛形を使う際に、それに不都合な場合、継承するという一面もあるんですか。完璧主義者の面もあるので、全て自分で作りたいと思ってしまうので、自分で作ったものを再利用する事に視点が言ってしまい大局をみていなかったのかもしれません。最初はユースケースとかで「シンプルな日記」というものの使い方や機能などをある程度決めます。これをベースにして、これに対する機能変更や保守を想定したり、流用製を考慮したりするのであって、それを定義せずにどんなクラスを作りますか、と聞くのは難しいと思いますが。目的があっての設計/方法論なので。ご質問の件は設計/分析上の用語としては「クラス抽出」と呼ばれると思いますので、これで検索してみてください。名前/名詞抽出とかいろいろな方法論が見つかると思います。入門用で、最近私がわかり易いと思って進めている本を参考に載せておきますので、ご興味があれば本屋さんなどでご覧になってみてはいかがでしょう。言語としては一応組み込み系のC++が想定されてますが、本質はモデリング~製造~評価まで一通りを舐めている本なので他言語でも考え方は使えると思います。理論に走るというよりは、構造化とかで経験もあり基礎はわかっているような人がオブジェクト指向で作ってみる場合の入門指南書だと思ってます。目的は、質問者様の方である程度決めていただいて結構です。合えて言及しませんでした。「自作で日記を作るとしたら。」と置き換えていただいてもかまいません。プログラム全部を書いてほしいのではなく、クラスのイメージがわかる青写真の段階で問題ありません。通報するこの回答へのお礼クラス抽出で検索してみようと思います。実際の場面で、クラス抽出のお手本を見ていないので、どう言うクラス抽出がいいのかが、ぴんときていない状態です。ありがとうございます。オブジェクト指向の本当の便利な点。オブジェクト指向全般、及び、クラス設計について。Inc.Q質問する(無料)Q&A検索goo検索gooIDで新規登録・ログイン新規登録する(無料)会員の方はこちら外部サービスのアカウントで新規登録・ログインYahoo!で新規登録・ログインGoogleで新規登録・ログインTwitterで新規登録・ログインFacebookで新規登録・ログインdアカウントで新規登録・ログイン※各種外部サービスのアカウントをお持ちの方はこちらから簡単に登録できます。お客様の許可なしに外部サービスに投稿することはございませんのでご安心ください。会員でない方、会員になるとあなたも質問や回答ができるようになります!!親切・丁寧な回答が集まる場30分以内に回答がもらえ回答数は平均3件!匿名(ニックネーム)での投稿なので。