オブジェクト指向プロジェクトをどのように設計しますか？[閉まっている]

多くのクラスがあり、拡張可能である必要がある大規模なプロジェクト（私にとって）に取り組んでいますが、プログラムをどのように計画するか、およびクラスがどのように相互作用する必要があるかわかりません。

私は数学期前にOODコースを受講し、そこから多くを学びました。UMLの作成や、要件ドキュメントのオブジェクトやクラスへの変換などです。シーケンス図も学びましたが、どういうわけか講義を逃したり、なかなか私にこだわりませんでした。

以前のプロジェクトでは、コースから学んだ方法を使用してみましたが、通常は「ええ、私が考えていたもののように見えます」と言えるとすぐに、マックを掘って追加したくありません。新機能。

Steve McConnellのコードコンプリートのコピーを手に入れました。これは、ここや他の場所で素晴らしいと絶えず聞いています。デザインの章を読みましたが、探している情報が得られなかったようです。彼はそれがカットアンドドライプロセスではなく、主にヒューリスティックスに基づいていると彼が言っているのを知っていますが、私は彼のすべての情報を取得して私のプロジェクトに適用することはできないようです。

では、高レベルの設計段階（プログラミングを始める前）で、必要なクラス（特に、「実世界のオブジェクト」に基づいていないクラス）を決定し、それらがどのように相互に作用するかを判断するにはどうすればよいでしょうか。

具体的には、どのような方法を使用することに興味がありますか？通常、最終製品を厳密に表す優れたクリーンなデザインを実現するプロセスはどのようなものですか？

（クラス図を取得する）初期設計に使用する手順は次のとおりです。

1. 要件の収集。クライアントと話し、ユースケースを考慮に入れて、ソフトウェアに必要な機能を定義します。

2. 個々のユースケースの説明を作成します。

3. ナラティブを調べ、名詞（人、場所、物）を候補クラスとして、動詞（アクション）として、メソッド/動作としてハイライトします。

4. 重複する名詞を破棄し、共通の機能を除外します。

5. クラス図を作成します。Java開発者の場合、SunのNetBeans 6.7には、図表作成と往復エンジニアリングを可能にするUMLモジュールがあり、無料です。Eclipse（オープンソースのJava IDE）にもモデリングフレームワークがありますが、私はそれを使った経験がありません。オープンソースツールであるArgoUMLを試してみるのもよいでしょう。

6. OODの原則を適用してクラスを編成します（共通の機能を除外し、階層を構築するなど）。

スコットデイヴィスのコメントに加えて、

1. 開始する前に、プログラムの内容を完全に理解していることを確認してください。あなたのプログラムは何ですか？それは何をしませんか？解決しようとしている問題は何ですか？

2. 最初の一連のユースケースは、プログラムが最終的に実行するすべてのもののランドリーリストであってはなりません。プログラムの目的の本質を捉えた、考えられる最小のユースケースのセットから始めます。このウェブサイトの場合は、例えば、コアユースケースがあるかもしれないでログ、質問をし、質問に答えると、ビューの質問と回答。評判、投票、コミュニティウィキについては何もありません。何を狙っているのか、その本質そのものです。

3. 潜在的なクラスを思いついたら、それらが表す名詞だけでなく、それらがどのような責任を持つかという観点からそれらを考えないでください。これは、プログラムの実行中にクラスが互いにどのように関連しているかを理解する上で最大の助けになることがわかりました。「犬は動物」や「子犬は母親が1人」などの関係を思いつくのは簡単です。通常、オブジェクト間の実行時の相互作用を表す関係を理解することは困難です。あなたはプログラムのアルゴリズムであり、少なくともオブジェクトと同じくらい重要であり、各クラスの仕事が何であるかを明記しておけば、それらの設計ははるかに簡単になります。

4. 最小限のユースケースとオブジェクトのセットを取得したら、コーディングを開始します。あまり機能せず、おそらくがらくたのように見えても、実際にできるだけ早く実行されるものを入手してください。これは出発点であり、紙に記入するかもしれない質問に答えるように強制します。

5. 次に戻って、より多くのユースケースを選び、それらがどのように機能するかを書き、クラスモデルを変更し、さらにコードを書きます。最初のカットと同じように、意味のあるものを追加しながら、一度に少しずつ始めます。すすぎ、繰り返します。

ちょうど私の2セント。うまくいけば、それは便利です。

機会があったとき、私は通常「3回反復ルール」と呼んでいるものを使用します。

最初の反復（またはスタートアップ）では、モデルオブジェクト、アルゴリズム、および予想される（実際には予想されるが、多分そうではない）に従って、アプリケーションの一般的なレイアウトを考案します予想される）将来の方向性。私は設計ドキュメントを書きませんが、複数の人を調整する必要がある場合は、依存関係の分析と必要な時間の見積もりとともに、手順の大まかなスケッチがもちろん必要です。私のように、より機敏な方法を好む場合は、このフェーズを最小限に抑えるようにしてください。強力な設計フェーズが必要な場合があります。特に、プログラムのロジックについてすべてがわかっていて、真実である場合や、コード内の機能間で多くの相互作用を計画している場合などです。この場合、特にGUIアプリでは、ユースケースまたはユーザーストーリーが提供する優れた高レベルのアイデアです。コマンドラインアプリ、特にライブラリの場合、開発する必要があるライブラリに対してコードを記述し、それがどのように表示されるかを確認する「プログラムストーリー」を作成してみてください。

この最初の反復の後、物事がどのように相互作用し、詳細と大まかなスポットを取り出し、スラップダクトテープパッチの問題を解決したかについて、よりよく理解できるようになります。この経験を利用して、大きすぎるものを改善、クリーン、ポリッシュ、分割し、断片化しすぎたものを合体し、デザインパターンを定義して使用し、パフォーマンスのボトルネックと重要なセキュリティ問題を分析します。一般に、これらの変更はすべて、作成した単体テストに大きな影響を与えますが、機能テストには影響を与えません。

この2回目のイテレーションを完了すると、十分にテストされ、文書化され、適切に設計された小さな宝石ができます。これで、エクスペリエンスと、3回目の反復を行うコードの両方が拡張されました。アプリケーションを改善するために、新しい機能とユースケースを追加します。大まかなスポットが見つかり、最終的には2番目のものに類似した4番目の反復に入ります。すすぎ、繰り返します。

これがソフトウェア設計に対する私の一般的なアプローチです。これはスパイラル設計に似ており、3か月の短い反復とアジャイル開発の要素を備えているため、問題を学び、ソフトウェアとその応用分野を知ることができます。もちろん、アプリケーションは、開発者の数百を伴うことが非常に大きい場合、それはそう、スケーラビリティの問題だ、物事はもう少し複雑で、これよりもあるが、最終的に私は、アイデアは常に同じ、と思い除算 ら impera。

要約すると：

1. イテレーション1では、それを味わって学びます
2. 反復2では、製品をクリーンアップし、将来に備えて準備します
3. イテレーション3では、新しい機能を追加して詳細を学習します
4. goto 2

これに関して私が知っている最も興味深いソースは、Bertrand Meyerによる第2版​​オブジェクト指向ソフトウェア構築のパートDです。

パートD：オブジェクト指向の方法論：メソッドを適切に適用する

19：方法論、20：デザインパターン：マルチパネルインタラクティブシステム、21：継承のケーススタディ：インタラクティブシステムで「元に戻す」、22： クラスを見つける方法、23：クラスデザインの原則、24：継承をうまく使う、25：便利なテクニック、26：スタイル感、27：オブジェクト指向分析、28：ソフトウェア構築プロセス、29：メソッドの指導

興味深いことに、第22章のクラスの検索方法はオンラインで入手できます。

それはしばしば繰り返されますが、完全に本当です-データを理解してください。

OOPの場合、クラスは重要な情報とそれらの相互作用について説明する必要があります。

データの動作と寿命をよく説明するメンタルモデルがある場合、クラスをレイアウトするのは簡単です。

これは単に拡張機能です：何をしようとしているのか正確に把握してください。

振る舞い駆動開発を使用してみてください。古い習慣を打破するのは難しいでしょうが、現実世界での開発に関しては、BDDが本当に最善の策であることがわかりました。

http://behaviour-driven.org/

大規模なプロジェクトの問題は、コンポーネント間のすべての相互作用を監視できないことです。したがって、プロジェクトの複雑さを軽減することが重要です。クラス図とシーケンス図は、この設計段階では詳細すぎます。

最初に、より高い抽象化レベルから考えてみてください。主要なコンポーネントとその責任（他のコンポーネントへのインターフェース）について考え、インスピレーションを得るためにいくつかのアーキテクチャパターンを確認します（設計パターンではなく、これらは低レベルです！MVCと多層はアーキテクチャパターンの例です）。かなり大きなプロジェクトの場合、そのようなビューには3〜5個のコンポーネントが必要です。

その後、特定のコンポーネントにズームインして、それを設計しようとします。これで、デザインパターンとクラス図のレベルに到達しました。プロジェクトのこの部分に焦点を当ててみてください。他のコンポーネントの1つに責任を追加する必要がある場合は、それをドキュメンテーション/ ToDoリストに追加してください。この時点で影響が非常に早く変化することを考えて時間を無駄にしないでください。設計がより堅固な場合は見直してください。

この時点で各コンポーネントを完全に設計する必要はありませんが、実装されていないコンポーネントのインターフェースを実装し、シンプルでありながら有用な応答を生成するコードを用意するのが賢明でしょう。このようにして、一度に1つのコンポーネントの開発（および設計）を開始し、妥当な程度にテストすることができます。

もちろん、新しいコンポーネントが完成したら、次に進む前に、それらが互いにどのように統合されるか（そして統合されるかどうか）をテストする必要があります。

要するに、オブジェクト指向と情報非表示の原則を取り入れて、それを別のレベルに引き上げます！

PS：設計中に多くのスケッチを行います。それは実際の建築物のようです！

PPS：さまざまな角度から問題に取り組み、枠の外で考えます（ただし、枠は道のりかもしれません）。仲間と話し合うことはこれに非常に役立ちます...そして昼食について話し合うことができます。

妥当な成功を収めて実際のプロジェクトで使用した手法は、Wirfs-Brockの本に触発された責任主導型の設計です。

トップレベルのユーザーストーリーから始めて、同僚と一緒にホワイトボードで、彼らが意味するハイレベルなやり取りをスケッチします。これにより、大きなモジュールが何であるかについての最初のアイデアが得られます。プレイのような高レベルのCRCカードの1つまたは2つの反復では、主要なコンポーネントのリスト、それらが何をするか、それらがどのように相互作用するかを安定させる必要があります。

次に、責任が大きいか複雑な場合は、より高いレベルの相互作用によって識別される主要な操作ごとにモジュール内の相互作用を再生することにより、オブジェクトになるほど小さくシンプルなものになるまで、それらのモジュールを絞り込みます。

いつ停止するかを知ることは判断の問題です（これは経験のみに伴います）。

デザインパターン

創造的なデザインパターン

シングルトン-クラスのインスタンスが1つだけ作成されていることを確認し、オブジェクトへのグローバルアクセスポイントを提供します。

ファクトリ（ファクトリメソッドの簡易バージョン）-インスタンス化ロジックをクライアントに公開せずにオブジェクトを作成し、共通のインターフェースを介して新しく作成されたオブジェクトを参照します。

ファクトリメソッド-オブジェクトを作成するためのインターフェイスを定義しますが、インスタンス化するクラスをサブクラスに決定させ、共通のインターフェイスを通じて新しく作成されたオブジェクトを参照します。

抽象ファクトリー-クラスを明示的に指定せずに、関連オブジェクトのファミリーを作成するためのインターフェースを提供します。

ビルダー-オブジェクトを作成するためのインスタンスを定義しますが、インスタンス化するクラスをサブクラスに決定させ、構築プロセスをより細かく制御できます。

プロトタイプ-プロトタイプのインスタンスを使用して作成するオブジェクトの種類を指定し、このプロトタイプをコピーして新しいオブジェクトを作成します。

行動設計パターン

責任の連鎖-リクエストの送信者をそのレシーバに接続することを回避し、他のオブジェクトにリクエストを処理する可能性を与えます。-オブジェクトはチェーンの一部になり、オブジェクトの1つがそれを処理するまで、チェーン全体で1つのオブジェクトから別のオブジェクトにリクエストが送信されます。

コマンド-要求をオブジェクトにカプセル化し、さまざまな要求を持つクライアントのパラメーター化を許可し、要求をキューに保存できます。

インタプリタ-言語を指定して、その文法の表現を定義し、その表現を使用して言語の文を解釈します/ドメインを言語に、言語を文法に、文法を階層的なオブジェクト指向設計にマップします

イテレータ-基礎となる表現を公開せずに、集約オブジェクトの要素に順次アクセスする方法を提供します。

Mediator-オブジェクトのセットがどのように相互作用するかをカプセル化するオブジェクトを定義します。Mediatorは、オブジェクトがお互いを明示的に参照しないようにすることで疎結合を促進し、相互作用を個別に変化させることができます。

オブザーバー-オブジェクト間の1対多の依存関係を定義して、1つのオブジェクトの状態が変化したときに、そのすべての依存オブジェクトに通知され、自動的に更新されるようにします。

戦略-アルゴリズムのファミリーを定義し、それぞれをカプセル化して、それらを交換可能にします。戦略により、アルゴリズムはそれを使用するクライアントから独立して変化します。

テンプレートメソッド-操作でアルゴリズムのスケルトンを定義し、一部のステップをサブクラスに延期します。テンプレートメソッドを使用すると、サブクラスはアルゴリズムの構造を変更せずに、アルゴリズムの特定のステップを再定義できます。

訪問者-オブジェクト構造の要素で実行される操作を表します。訪問者を使用すると、操作する要素のクラスを変更せずに新しい操作を定義できます。

Nullオブジェクト-特定のタイプのオブジェクトの欠如に対する代理としてオブジェクトを提供します。/ Nullオブジェクトパターンは、インテリジェントな何もしない動作を提供し、共同作業者から詳細を隠します。

構造設計パターン

アダプター-クラスのインターフェースをクライアントが期待する別のインターフェースに変換します。/アダプターを使用すると、互換性のないインターフェースが原因でクラスを連携させることができます。

ブリッジ-オブジェクトをツリー構造に構成して、部分全体の階層を表します。/ Compositeを使用すると、クライアントは個々のオブジェクトとオブジェクトの構成を均一に処理できます。

複合-オブジェクトをツリー構造に構成して、部分全体の階層を表します。/ Compositeを使用すると、クライアントは個々のオブジェクトとオブジェクトの構成を均一に処理できます。

デコレータ-オブジェクトに動的に追加の責任を追加します。

Flyweight-共有を使用して、内部状態の一部が共通であり、状態の他の部分が変化する可能性がある多数のオブジェクトをサポートします。

Memento-カプセル化に違反することなくオブジェクトの内部状態をキャプチャし、必要に応じてオブジェクトを初期状態に復元する手段を提供します。

プロキシ-オブジェクトへの参照を制御するためのオブジェクトの「プレースホルダー」を提供します。

BlueJとActiveWriterを使用して、オブジェクトの理解を深め、理解を深めることをお勧めします。お勧めの本も素晴らしいリソースです。

ウィキペディアから：

BlueJはJavaプログラミング言語の統合開発環境であり、主に教育目的で開発されていますが、小規模なソフトウェア開発にも適しています。

さらに、それはUMLを使用しており、私にとって、オブジェクトのモデリングに関するいくつかのことを理解するための良いリソースでした。

代替テキストhttp://www.ryanknu.com/ryan/bluej.png

ActiveWriterは、エンティティと関係をモデル化するツールであり、コードを生成し、簡単に変更できます。時間を節約でき、アジャイル開発には非常に適しています。

_{（ソース：altinoren.com）}

まず第一に-デザインはあなたの魂から来るべきです。あなたはすべての繊維でそれを感じなければなりません。私は通常、何かを始める前に2〜3か月歩きます。通りを歩いているだけです（本当に）。そして考える。ウォーキングはいい瞑想ですよね。だから、集中力を高めることができます。

次に、自然なオブジェクト階層が存在する場所でのみOOPとクラスを使用します。それを人為的に「ねじ込み」しないでください。厳密な階層が存在しない場合（ほとんどのビジネスアプリケーションのように）-手続き型/機能型を選択するか、少なくともオブジェクトを、分離されたアクセサーを持つデータコンテナーとしてのみ使用します。

そして最後-これを読んでみてください：創造的思考のアルゴリズム

ただ引用する http://www.fysh.org/~katie/computing/methodologies.txtを

そして、RUPの中核となるのは、OO設計の才能を使わなければならない小さな領域です...持っていない場合は、100mを走らせる方法論があるようなものです。

「ステップ1：本当に速く走ることについて書く。ステップ2：行き、競馬場の計画を描く。ステップ3：本当にタイトなライクラショーツを買う。ステップ4：本当に、本当に、本当に速く走る。ステップ5：最初にクロスラインを走る。 」

難しいのはそのステップ4です。しかし、1、2、3、5に重点を置いた場合、誰も気付かない可能性があり、100メートルであることには「秘密」があると考えるアスリートに、この方法論を売ることで多額のお金を稼ぐことができるでしょう。ランナーオーバー

多くの著者が本を書くのに使用していると質問しました。方法論はいくつかあり、「最もきれい」に見える方法を選択する必要があります。Eric Evansによる「ドメイン駆動設計」の
本をお勧めします。また、サイトdddcommunity.orgも確認してください。

ここでの答えは非常に異なるはずですは、尋ねる人の実際の経験によって。

あなたがたった1年か2年の実務経験を持っているなら、あなたはそれがであるポイントに行く必要があります：どのようにあなたが本当にあなたのデータを知っているし、あなたが何をしようとして正確に理解してポイントを取得できますか？

ええ、あなたが5年以上実世界で働いてきたなら、あなたは多くのソフトウェア開発プロセスのモデルまたはテクニックのいずれかを選ぶでしょう。

しかし、本を読むだけでは経験はありません。良いリーダーシップの下で良いグループで働くことによって学ぶべきです。

それが不可能な場合は、自分で行ってください。おそらく非常に厄介なコードをコーディングし、エラーを学習し、すべてをダンプし、より適切なものをコーディングするなどして、反復を開始します。

コードベースについて多くを学びます。ツールはツールであり、何も教えません。

プロジェクトに関する専門知識をお持ちの場合は、バンキングなどのように取り組みます。オブジェクトを構造化するのは簡単で、それらの機能強化が一日おきにどのように行われるかを知っています。

その専門知識を持っていない場合は、その専門知識を持つ人と協力して、それらのアイデアを技術的な詳細に変換してください。

プロジェクト設計の構成方法について混乱している場合。盲目的に「プラグマティック・プログラマー」の本に従ってください。以前と同じ状況でしたが、その本の章を読んでみてください。違いがわかります。ソフトウェア開発者としての考え方が変わります。

1. 研究＆マスターデザインパターン。
2. 次に、ドメイン駆動設計について学びます
3. その後、要件収集を学びます

私は数学期前にOODコースを受講し、そこから多くを学びました。UMLの作成や、要件ドキュメントのオブジェクトやクラスへの変換などです。シーケンス図も学びましたが、どういうわけか講義を逃したり、なかなか私にこだわりませんでした。

4. ステップ3について知っています。習得する必要があります。つまり、それをあなたの第二の性質にするための多くの練習を通して。それは、あなたが学ぶ方法が、私たちが以前持っていた方法に単純に反するからです。だからあなたは本当にそれを習得する必要があります。さもなければ、あなたはいつも自分を元のやり方に戻すことに気付くでしょう。これは、テスト駆動型プロセスに似ています。多くのJava開発者は、数回の試行後にそれをあきらめます。彼らがそれを完全に習得しない限り、そうでなければそれは彼らにとって単なる負担です

5. 特に代替コースのユースケースを書きます。代替コースは開発時間の50％以上を占めます。通常、PMがあなたにタスクを割り当てるとき、たとえばログインシステムを作成するとき、彼はそれが簡単だと考え、1日で完了することができます。しかし、彼はあなたが考慮する必要があることを決して考慮しません、1。ユーザーキーが間違ったパスワードを入力した場合、2。ユーザーキーが間違ったパスワードを3回入力した場合、3。ユーザーがユーザー名を入力しなかった場合など。あなたはそれらをリストアップし、それをあなたの首相に見せ、彼に期限を再スケジュールするよう依頼する必要があります。

これは答えではないと思います 人々が聞きたいと思います。とにかく、私の意見を述べさせてください。

OOPは、優れたパラダイムとしてではなく、パラダイムの1つとして見なされるべきです。OOPは、GUIライブラリの開発など、特定の種類の問題を解決するのに適しています。また、大規模なソフトウェア会社が続くソフトウェア開発のスタイルにも適合します- デザイナーのエリートチームまたはアーキテクトの、UML図または他の類似の媒体でソフトウェアデザインを配置し、開発します。その設計をソースコードに変換します。OOPは、単独で作業している場合や、才能のあるプログラマーの小さなチームで作業している場合には、ほとんどメリットがありません。次に、複数のパラダイムをサポートし、プロトタイプをすばやく作成するのに役立つ言語を使用することをお勧めします。Python、Ruby、Lisp / Schemeなどが良い選択です。プロトタイプはあなたのデザインです。次に、それを改善します。目の前の問題を解決するのに最適なパラダイムを使用してください。必要に応じて、Cまたはその他のシステム言語で記述された拡張機能を使用してホットスポットを最適化します。これらの言語のいずれかを使用すると、拡張性も得られます無料で、プログラマーレベルだけでなく、ユーザーレベルでも。Lispのような言語はコードを動的に生成および実行できます。つまり、ユーザーは、ソフトウェア自体がコーディングされている言語で、小さなコードスニペットを記述することでアプリケーションを拡張できます。または、プログラムをCまたはC ++で作成する場合は、Luaなどの小さな言語用のインタープリターを組み込むことを検討してください。機能を公開プラグイン公開するその言語で書か。

ほとんどの場合、OOPとOODは過剰設計の犠牲者であるソフトウェアを作成すると思います。

要約すると、ソフトウェアを書くための私の好ましい方法は次のとおりです。

1. 動的言語を使用します。
2. その言語自体でデザイン（プロトタイプ）を記述します。
3. 必要に応じて、C / C ++を使用して特定の領域を最適化します。
4. 実装言語自体のインタープリターを介して拡張性を提供します。

最後の機能により、ソフトウェアは特定のユーザー（自分も含む）の要件に簡単に適応できます。

私はテスト駆動設計（TDD）を使用しています。最初にテストを記述することは、実際に、クリーンで正しいデザインに導くのに役立ちます。http://en.wikipedia.org/wiki/Test-driven_developmentを参照してください。

デザインパターンを学ぶ。過去2年間、OOPに関する私の個人的な革命でした。本を入手してください。これをお勧めします：

ヘッドファーストデザインパターン

これはJavaですが、任意の言語に拡張できます。

正直なところ、良いステップは前に戻ってフローチャートとシーケンス図を見ることです。それを行う方法を示す良いサイトがたくさんあります。プログラムの入力、計算、出力に必要なものを正確に把握しており、各ステップをプログラムの1つの部分に分解できるため、プログラムをクラスに分解する方法を見ると、非常に貴重です。

あなたが書こうとしているソフトウェアを設計するためにあなたが従うワークフローは何ですか？で答えたように？

有用なテクニックの1つは、固有の問題の説明を、現実の世界で見つけられるものに関連付けることです。たとえば、世界を席巻するような複雑な医療システムをモデル化しているとします。これをモデル化するためにすぐに呼び出すことができる例はありますか？

確かに。副薬局がどのように機能するか、または医者の部屋を観察します。

ドメインの問題を理解しやすいものにしてください。あなたが関連付けることができる何か。

次に、ドメイン内の「プレーヤー」が明らかになり始め、コードのモデル化を開始したら、「プロバイダー-コンシューマー」モデリングアプローチを選択します。つまり、コードはモデルの「プロバイダー」であり、あなたは「コンシューマー」になります。」

ドメインに関連し、それを高レベルで理解することは、設計の重要な部分です。

クラス構造を設計する冒険の最中に、疑似コードの作成から始めることが非常に役立つことに気付きました。つまり、私はアプリケーションのコードの一般的なフラグメントを最高レベルで「書く」ことから始め、それをいじって、現れている要素、実際、プログラマーとして使用したい要素を発見します。これは、モジュールとその相互作用の一般的な構造を設計するための非常に良い出発点です。数回の反復の後、構造全体がクラスの完全なシステムのように見え始めます。これは、コードの一部を設計するための非常に柔軟な方法です。プログラマ指向の設計と言えます。