コーディングする前にOOPシステムを設計する簡単なプロセスは何ですか？

プロジェクトを構築する必要が生じたときはいつでも、事前に計画や設計を考案するのではなく、いつでもそれを構築することができましたが、最初に必要なクラスを書いた後、プロジェクト全体を具体化し、ボトムアップで構築しました。これはソフトウェアを作成する適切な方法ではないことはわかっていますが、オブジェクト指向分析とデザインと呼ばれるものに頭を悩ますことは簡単ではありません。トップダウンの手順設計をより簡単に理解できます。それは、タスクをサブタスクに分解することで構成されているためです。しかし、オブジェクト指向の分析と設計は簡単に理解できません。どのようにコード化するかを知らない限り、必要なクラスとそれらがどのように相互作用するかを知る方法がわかりません。

クラスとオブジェクトの概念を設計プロセスに導入すると、問題をプロシージャとして実装できるものに分解することがなくなるため、トップダウンで設計することができなくなります。代わりに、私が主題について読んだ内容に従って、必要なクラスを決定し、ソフトウェアを実装するときに使用できる統一モデリング言語でさまざまなアーティファクトを作成する必要があります。しかし、私はこの種の設計プロセスを理解していません。すでにシステム全体を考えていなければ、どのクラスが必要になるのか、そしてどのように相互作用するのかをどうやって知るのですか？

これが私の問題です。私はオブジェクト指向プログラミングの概念を理解していますが、オブジェクト指向システムの設計方法を理解していません。それらの概念は、私が知っている任意のオブジェクト指向プログラミング言語で使用できます。したがって、私には、私にとって意味のある方法でオブジェクト指向システムを設計するために使用できる単純なプロセスを説明してくれる人が必要です。

トップダウンウォーターフォールスタイルOOADは、作成するコードがオブジェクト指向であることを保証しません。私はそれを証明する厳格なOOAD生成コードの山を見てきました。OOが混乱している場合は、ここを参照しないでください。あなたはそれを見つけることはありません。オブジェクト指向では、トップダウンで設計する必要はありません。

クラスに飛び込むことがコードの作成方法である場合は、そうしてください。ヒントをお話ししましょう。先延ばし。

クラスがまだ存在しない場合でも、それを使用するコードを記述してクラスを設計するのがいかに簡単かは驚くべきことです。手順を忘れます。構造を忘れます。自分に合った抽象化レベルを一貫して取得し、それに固執するだけです。誘惑に負けて、それに細部を混ぜないでください。あなたが現在の抽象化からあなたを連れて行くものはすべて、何らかの方法でそれが知る必要があることを知っているいくつかの他のオブジェクトにあるかもしれないいくつかのメソッドで実行できます。あなたに手渡されるように頼むことができる何かを構築しないでください。

そのように書くことを学ぶと、一生懸命に努力することなくOOをしていることがわかります。これにより、オブジェクトの使用方法（インターフェース）、およびどのオブジェクトが他のどのオブジェクトについて知っているかという観点から、オブジェクトを確認する必要があります。UMLダイアグラムの主な2つのポイントは何でしょうか？

あなたがその思考モードに入ることができるなら、残っているのはアーキテクチャです。私たちはまだそれを理解しています。MVCからクリーンアーキテクチャ、ドメイン駆動設計まで。それらを研究して遊ぶ。機能するものを使用します。100％信頼できる何かを見つけたら、戻ってきて私に知らせてください。何十年もこれをやっていて、私はまだ探しています。

コードでオブジェクト指向のテクニックを使用できると主張しているので、オブジェクト指向のシステムを設計する方法をすでに知っていることで、問題はいつできるかではなく、いつ問題になるかが問題になると思います。長期的な計画の方法ではなく、短期間の反復的な方法でオブジェクト指向の設計に慣れているようです。

最初のプロジェクトを開発するとき、それはときだと、計画および設計に非常に困難になる可能性がアジャイル開発はよりも優先される滝の開発滝計画の壮大な範囲は、多くの場合、ソフトウェアプロジェクトの複雑さのすべてをキャプチャしないように、。

「初期計画」なしでオンザフライで開発することは次のように主張します。

「...ソフトウェアを作成する適切な方法ではありません...」

最初の計画が十分に詳細でないことが問題である場合は、少し時間をかけて最初の考えを説明してください。あなたが書く予定のプログラムの最初の部分は何ですか？何が必要ですか？おそらく、最初にどんなオブジェクトを考えるのではなく、そこからどのような機能と計画を考えるかです。

文書化/設計/ UMLスキルに自信がないことが問題である場合は、既存のプロジェクトを文書化して練習します。

個人的には、設計が完全にオブジェクト指向であることを心配しないことをお勧めします。ほとんどのシステムは100％オブジェクト指向ではありません。目標は、システムのより良い理解と視覚化を作成することであり、完全な抽象化ではありません。オブジェクト指向は特効薬ではなく、ベルト上のもう1つのツールです。

OOADはユートピアです。だからといって、それが最善のアプローチであるという意味ではありません。それは、私の控えめな見解では、真に達成できるものではないということです。私の経験では、それが要件であろうと詳細であろうと、あるいは依存関係を完全に置き換えることを強制する依存関係の競合でさえ、何かが常に変化します。この方法で学んだからであれ、それが私にとって最も自然なことであれ、コードを書いているとき、デザインに対する私のアイデアは最も容易に思い浮かびます。コードを作成しようとしていて、コードをどのように構造化するかが明確にわからない場合は、最初に問題を真に理解するために時間を費やすようにしますが、多くの場合、クラスの必需品と私はそれを作ります。

私のアドバイスは、あなたのためにできる最も良いことは、ファサードを使用したコードであり、入力と出力にシンプルなインターフェースを提供することであり、入力と出力が頻繁に変更されないことを願っています。仮にそうであっても、仕様上の問題（必要性・運用・機能の変更）である以上、設計上の問題ではないことをご理解ください。これにより、プログラムまたはコードのセクションを呼び出す人に対してプログラム内で共振する問題に対してプログラムがいくらか抵抗力を持つようになります。

オブジェクト指向システムの設計に関係するものについては、オブジェクト指向であるべきでないときにすべてのものをオブジェクト指向にしようとするために何かを言う必要があります。これは、C＃やJavaなどのOOPプログラミング言語でよくある間違いであり、すべてをオブジェクトとして処理しようとすることです。その結果、クラスの単一のインスタンスが作成され、通常は状態をまったく変更しない静的メソッドが実行されます。とはいえ、もちろん静的なメソッドを書くほうが自然だと感じても、間違っているとは思わないでください。それは常に間違った本能ではありません。

次のいずれかの質問に「はい」と答えた場合は、クラスの使用を検討する必要があります。

• 同じ概念（つまり、姓、名、住所）に関連する情報のグループはありますか？
• 複数の情報を必要とする操作（つまりcalculatePrice(basePrice, quantity, tax)）を実行する必要がありますか？
• 大きなコードブロックが同じまたは類似の情報（if(type == "cat") { meow(name); } else if (type == "dog") { bark(name); }==> animal.speak()）を使用し てわずかに異なる操作を実行する場合、elseがありますか？
• 複数の特定のタスクを実行し、少し大きくなりすぎている既存のクラスはありますか？

しばらくすると、クラスを作成することが第二の性質になります。コードが上記のケースのいずれかに該当する場合でも、それらを使用することを恐れないでください。お役に立てば幸いです。

Doc Brownがコメントで指摘した点は、コメントよりもはるかに目立つに値すると思います。彼は完全に正しいからです。

「これがソフトウェアを作成する適切な方法ではないことがわかりました」-誰があなたにこれを言ったのですか？「デザインはコーディング前に行うことで、おそらくファンシーなUMLダイアグラムを描くことによって」という一般的な罠に陥るようです。この誤解を解消するために、ジャックリーブスの「Code as Design」から始めることをお勧めします。– ドクブラウン 6月21日5:27

@Laiv：「コーディング」は、他のエンジニアの分野ではデザインと呼ばれるものの一部です。住宅建設では、設計から最終製品までのステップは、ピリングレンガとモルタルを使用して行われます。プログラミングでは、この手順は、デザイン（=プログラム）を最終製品（=実行可能バイナリ）に変換するときにコンパイラーによって実行されます。そして、それは新しい知恵ではありません。リーブスのエッセイは25歳です。– Doc Brown 6月21日6:39

この同じ感情は他の場所にも反映されます。Glenn Vanderburgの「実際のソフトウェアエンジニアリング」に関する講演、およびある程度は「クラフト、エンジニアリング、およびプログラミングの本質」と「クラフトおよびソフトウェアエンジニアリング」に関する講演を検討してください。また、C2 wiki のWhatIsSoftwareDesignおよびTheSourceCodeIsTheDesignページ/ディスカッションも検討してください。

設計であるコードの概念は、どのパラダイムにも固有ではありません。オブジェクト指向、機能、手続き型、ロジック、またはその他のものに同様に適用できます。基本的な考え方は同じです-デザインはソースコード自体です。構築の行為は、ソースコード（デザイン）がインタープリターまたはコンパイラーによって使用可能なものに変換されるプロセスです。

複雑なシステムでは、コードの記述を始める前に、サブシステム、コンポーネント、モジュール、サービスを特定し、要件を割り当てるなど、ある程度レベルの高いアーキテクチャ設計が存在する可能性があります。UMLは、このアーキテクチャ設計に関する作成、文書化、およびディスカッションを支援する方法として使用できます。アイデアを検討UMLモードのMartin Fowler氏で説明すること、特にスケッチとしてUMLやNotesなどUML。また、アジャイルモデリング- 初期アーキテクチャモデリング、反復モデリング、およびジャストベアリーグッドエナフモデルからのアイデアもいくつか考慮してください。

つまり、ソフトウェアを構築する正しい方法は、プロジェクト全体を具体化することではないということです。最も重要な（現時点での）要件を理解し、技術的な依存関係と要件間のトレードオフを特定し、ソフトウェアがソフトであることを利用するのに十分な時間を費やす必要があります。また、デザインを作成して何かを作成するコストが非常に低いことも認識してください（特に、他の多くのエンジニアリング分野でデザインを作成して何かを作成する場合と比較して）。したがって、設計（コーディング）アクティビティを反復処理し、行った作業を段階的に構築または変更することがいかに簡単で安価かを利用します。

OOADは、エンティティを識別し、現実のオブジェクトまたは概念をある程度の抽象化にモデル化することです。最初にクラスを作成する代わりに、インターフェイスを作成する方が簡単であると理解できます。まだ実装する必要がないため、コードはコンパイルされます。

OOADは、システムで大きなモジュールとして考える可能性を排除していません。あなたはまだそれを行うことができます。各モジュールは、一連のユーザーストーリー（ユースケース）を満たすために存在します。そのようなユーザーストーリーには、それらを実現するために協力するクラスが必要です。

手続き型OOアプローチの主な違いの1つは、通常、手続き型思考は要件を画面にマッピングするのに対し、OODは、フロントエンドを残してフードの下で何が起こるかを考える傾向があるということです。

エクストリームプログラミングには、CRCカードと呼ばれる手法があります。CRCは「class-responsibilities-collaborators」の略です。

基本的に、明確なクラスを識別し、それぞれにカードを割り当てます。クラスInvoiceに独自のカードがあるとします。

すべてのカード保持クラスについて、そのクラスの責任がどのようなものになるかを記述します（たとえば、「総計を計算します」）。

また、すべてのカード保持クラスについて、そのクラスが自分の責任を果たすために何かを求めなければならない他のクラスを記述します。ここでInvoiceは、コラボレーションの必要性をInvoiceDetail発見したり、そもそもそのようなクラスが必要であることを発見したりする場合があります。

自分が所属していると考えていた一部の責任がInvoce、実際にはその共同作業者の1人に属していることに気付くかもしれません。

演習の後、すべてのカードはクラスになり、すべての責任はメソッドになり、すべてのコラボレーション関係は、構成、集約、または単なる呼び出しになります。

その運動は、ビジネスマンでさえ参加するグループで行うことができます（そしてすべきです）。

このテクニックの詳細については、次のリンクをご覧ください。

http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card

http://www.extremeprogramming.org/rules/crccards.html

CRCカードの例：

ソフトウェア専門家のコミュニティとしての私たちにとっての主な課題。より具体的には、オブジェクト指向の設計実践者は、すべての問題/タスクをプログラミングパーツに具体化することです。それがタスクであるか - 関数として表されるか、またはタスクのアクターであるか- [OOADに向けて駆動する] インターフェース / クラスとして表されます。ソフトウェア設計の習慣を進化させるにつれ、さまざまな方法論/フレームワークに関する知識を継続的に獲得します。私たちの視点は、オブジェクトを明確に分離し、どのオブジェクトがどの機能を実行するのかについて、ますます洗練されています。

周りにオブジェクトが存在することで問題をサブ問題に分解することに関しては、あなたはまだ便利にそれを行うことができます。また、オブジェクトとインターフェースに性質と目的を与えるのに便利です。あなたがしなければならないことは、問題のステートメントを視覚化し、どのオブジェクトにどの目的/機能を与えることができるかを考えることです。

自動車の範囲の例を使用してさらに説明し、同じオブジェクトモデルを視覚化する2つの異なる方法を強調します。

自動車のさまざまなカテゴリーにまたがる自動車メーカーの例を見てみましょう：商用車、消費者車（セダン、ハッチバック、ステーションワゴン）など。

メーカーがカテゴリと目的を明確に分離するために、クラスを作成する方法はいくつかあります。

1. 車両のカテゴリー（市場セクター）に基づく：大型車両、消費者向け車両[セダン、ハッチバック、ステーションワゴンなど]

2. エンジン容量と運転方法に基づいて：800-1500 CC、> 1500 CCなど

製造業者がこれらの分類のそれぞれに属するオブジェクトに機能を個別に与えることができる最良の方法では、適切な基礎となるオブジェクト設計を選択し、その上にモデルを構築できます。