オブジェクト指向の分析と設計(OOA&D)の概念に少し混乱しています。
OOA&Dでは、実行可能な概念ドメインモデルを作成するためにどのような推奨に従う必要がありますか?
そのプロセスでクラスをどのように識別する必要がありますか?私は、ユースケースの名詞を候補クラスとして、動詞を操作/責任として示す、さまざまな英語の分析と精製プロセスについて読んだことがあります。明らかに、クラスを理解するためにその洗練を適用するさまざまな方法があります。
そこから、たとえば、CRCカードを使用して、責任とコラボレーション、さらにクラスの候補者を見つけることができます。しかし、CRCカードはあまり人気がないのではないかと思うので、他の方法について聞きたいと思います(ただし、必要に応じてCRCカードを推奨することもできます)。
また、実装の詳細(概念的なものではなく、より具体的で技術的なクラス)について、OOA&Dでそれらを決定するプロセスはありますか?それはどのように達成されますか?
OOAとOODを別々に扱い、回答する際にそれらに関連する手順を明確にしてください。これは、それらのクラスがどのように見つけられるかについて私に物事を明確にするのに役立つと思います。
OOA&Dでは、正確な概念的なドメインモデルを作成するためにどのような推奨事項に従う必要がありますか?
Eric EvansによるDomain-Driven Designのコピーを入手することをお勧めします。これは、ドメインの専門家と話し、アイデアをソフトウェアモデルに抽出するプロセスを説明する優れた本です。この本の中心的なアイデアの1つは、関係者とプログラマーの両方が理解できるシステム用のユビキタス言語を開発することです。人々が常に話し合う「もの」がある場合、おそらくあなたのコードのクラスです。
また、実装の詳細(概念的なものではなく、より具体的で技術的なクラス)について、OOA&Dでそれらを決定するプロセスはありますか?
一般的に言って、適切なドメインの概念とインターフェースがあれば、「テクニカル」クラスはかなり簡単に配置できます。データベース、Webサービス、IoCコンテナーなどの詳細は、ドメインモデルを外部の世界に接続するためにのみ存在するため、残りのソフトウェアを機能させる最も単純なソリューションを選択してください。
短い答え:いいえ。優れたオブジェクトモデルを生成する統一された機械的プロセスはありません。モデリングは創造的で社会的なプロセスであり、通常は他の人と話したり、理解したりする過程で、問題を分解するさまざまな方法が考えられます。
明確にするためにそれは近くさえないです。結果を判断することさえも完全に主観的であり、ソフトウェアエンジニアリングが何らかの形で「エンジニアリング」であると多くの人が信じていることを考えると驚くべきことです。
たとえば、私は通常、次の制約を満たそうとします。
多くの人が上記に反対するでしょう。ほとんどの人は、「貧血」オブジェクト、つまりレコードと構造体で完全に問題ありませんが、上記はそうではありません。
私が言おうとしているのはオブジェクト指向がどのように見えるかについても同意しませんでしたです。もちろん、本やルール、ベストプラクティスはたくさんありますが、それらの多くは矛盾しているか、個人の解釈に依存しています。基本的には自分のやり方でやらなければならない。
基本的に、私たちは彼らの消費者(多くの場合、私たち自身)に役立つ抽象化を設計したいと考えています。
私は一般に、これらの抽象化がどのように使用されるか(たとえば、実装の詳細についてではなく)について考えることを推奨しています。良い抽象化は使いやすいです。
また、ほとんどのOO言語で作成できるさまざまな種類の抽象化について話しましょう。
これらはそれぞれ、より多くのものをバンドルします。関数は、機能を入力と出力にバンドルします。クラスは、カプセル化された状態とともに複数の機能(別名メソッド)をバンドルします。インターフェイス(または基本クラス)は、複数のさまざまな実装にわたって機能を作成します。また、名前空間は、相互に作用し合う、または関連するクラスのフォレストを定義します。
良い抽象化が完了しました。あるものから別のものにナビゲートできる場合、おそらくその逆も同様です。消費するクライアントは、単一の抽象化で処理できる場合に2つ以上のアイテムを管理する必要はありません(たとえば、別々のxとy対、座標として一緒にバンドルされているか、別々の関数のエンコードとデコードのペアと、一緒にバンドルされているか)。インターフェース)。
クラスのみの観点から考えるだけでなく、ドメインに必要な抽象化をより広範囲にモデル化する必要があります。概念とその関係を特定し、ナビゲーション(トラバーサル/検索/クエリ)をサポートし、変更(コマンド)の動作をサポートし、すべてモデル化されたドメインの観点からできる限り直接的に機能できるように、消費するクライアントプログラマにとっては簡単なことです。
ソフトウェアは進化するので、最初から完璧にする必要はありません。デザインから始めて、クライアントを利用することの有用性を確認できます。たとえば、クライアントが複数のオブジェクトをペアまたはセットとして管理する必要がある場合、それはおそらくモデリングする必要がある抽象化が欠落していることを示しています。
私の視点から、analytical
とsynthetical
(18世紀の哲学に由来する)またはもっと現代的なものと呼ぶ2つのアプローチがあります:top-down
およびbottom up
。以前の用語は、あなたが何をしているのかを示しているので、より詳しく説明しています。
I)分析方法
ドメインに入ると、何が起こっているかをある程度理解できます。 e-commerceCustomers
、Orders
、Products
などを扱っているとします。
正確な概念ドメインモデルを作成するには、どのような推奨事項に従う必要がありますか?
この道を行くと、答えは
ビジネスドメインを知る
これはanalyticalと呼ばれ、最初に分析し、次にコードを分析するという理由からです。
II)総合的な方法
私の運が良ければ、複数のパラダイム(Pythonなど)をサポートする言語を使用すると、[オブジェクト()に関する質問を回避するためにそれを活用できます。およびモジュールなど)最初に。このようにして、ビットごとにボトムアップで構築します-またはそれがあなたと呼ばれるようにsynthesize(グループ化し、グループ化します)など。
一般的に言えば、OOP
は約dataおよびbehaviorおよびgrouping data and accordinging behaviorを一緒にしたものです(私の3つの柱があります。視点は後で来る)。
しかし、プロジェクトを開始するとき、ほとんどの場合、データをグループ化する方法がわかりません。もちろん、上記のように、order
を使用することの「簡単な部分」があります。
Pythonのような言語を使用すると、必要なクラスの質問と、それらがどのように見えるかを後で延期できます。基本的なから始めます。 builtinsそして、いくつかの関数を記述し、それらを後でクラスにグループ化される可能性があるモジュールにグループ化しますが、関数が必要であることがわかるだけの場合もあります。
プロジェクトに長く取り組むほど、どのdataがどのようなbehaviourと「引き付ける」かがわかります。同じ種類のデータを処理する関数がたくさんある場合:クラスを考えて、コードをクリーンアップします。
正確な概念ドメインモデルを作成するには、どのような推奨事項に従う必要がありますか?
ここでの答えは:
objects
の概念をまったく使用せずに開始し、プロジェクト中のデータと動作の「魅力」を探します。
後者のほうが好きです。早く仕事を始めましょう。
しかし、両方の方法を合理的な方法で行うには、(構築された)経験が必要です。
その上:accurate
という用語をviable
に置き換えます。 機能するのモデルを作成する必要があります。 不正確かもしれませんが、現時点では十分に正確です。