問題タブ [object-oriented-analysis]

ドメイン駆動設計を使用して構築しているアプリケーションのいくつかの概念に問題があります。

次のレイヤーがあります。

• 応用
• ドメイン
• インフラストラクチャー

したがって、次のクラスがあるとします。

• Order
• EmailService
• OrderNotificationService
• OrderApplicationService

明らかに、Orderはドメイン層にOrderApplicationService入り、 はアプリケーション層に入ります。はEmailService、電子メールを送信するための汎用サービスであり、インフラストラクチャ レイヤーに実装されています。はOrderNotificationService、注文通知を送信するための特定の実装です。はOrderNotificationServiceを使用しEmailServiceて、実際の電子メールを送信します。

私の最初の質問はOrderNotificationService、ドメイン サービス、アプリケーション サービス、またはインフラストラクチャ サービスとして実装されるかどうかです。

次の質問では、次のオブジェクトを想定してみましょう。

• Employee
• SalesforceService

従業員がシステムに追加されたら、Salesforce にも追加する必要があるとしましょう。はSalesforceService、Salesforce api を使用してユーザーを登録するサービスです。SalesforceServiceアプリケーション サービスが従業員情報を送信するために使用するドメイン サービスまたは汎用インフラストラクチャ サービスとして実装されますか?

アドバイスをありがとう。

私は数日間、この問題について繰り返し考えてきました: 私はクラス情報を持っています

そのクラスは、任意のクラスのどこでも (継承またはプロパティとして) 使用できます。プロパティは、セキュリティに関連するかどうかと見なすことができます。その情報は設計時に認識されており、その特定のプロパティ用に保存する必要があります。

したがって、そのクラスをプロパティとして使用する一部のクラスでは、それに応じてメンバー「いいえ」を設定する必要があります。

最初の試みとして、次のようなカスタム属性を導入することを考えていました:

次に、クラス「IsRelevant」をインスタンス化したら、プロパティとそのクラスを調べて、必要に応じてカスタム属性を設定します。

IsRelevant.Prop.No => IsRelevant = true、たとえばIsNotRelevant.Prop.No => IsRelevant=false。

しかし、私が理解している限り、クラスのメタ情報 (属性) は、タイプごとに 1 回作成されるインスタンスです。したがって、カスタム属性の値を変更すると、そのクラスのすべてのインスタンスに対して変更されます (そのタイプにバインドされているため!?)

編集: これは、次のように行うことはできません:実行時に属性のパラメーターを変更する カスタム属性にアクセスするたびに、デフォルト値を持つ新しいインスタンスが作成されます。その属性への変更はそこに保存されません。

2 番目のアプローチは、その情報を外部クラスに保存し、すべてのモデル パスなどを保存することでした。情報が特定のクラスに属しているため、私はそれが好きではありません。

3 番目のアプローチは、その情報を格納するディクショナリを保持するインターフェイスを実装することでした。

そして、セキュリティ関連のプロパティを持つすべてのクラスは、それを実装する必要があります。そのクラスをインスタンス化するたびに、辞書に情報を追加する必要があります。これは私が思いついた最善の解決策です。情報を保持するクラスは、必ずしもディクショナリである必要はありません。これは、2 番目のステップで、潜在的なセキュリティ関連プロパティを持つインスタンスに、それが本当に関連しているかどうかを問い合わせたいからです。したがって、そのプロパティを「セキュリティ関連の情報コンテナー」のメソッドに渡し、そのプロパティが関連しているかどうかを尋ねることができます。

だから私は基本的に誰かがその情報を保存したり、それにアクセスしたりするためのより良いアイデアを持っているかどうかを尋ねています.

そのため、この問題に関する一般的な結論を次に示します。

• プロパティがセキュリティに関連しているかどうかの情報は、実際にはランタイム情報ではなく、事前に入手できます。理想的には、「静的」な方法で保存したいと思います
• 結合を避けるためにその Info クラスを使用する他のクラスではなく、その情報について知る必要があるため、情報はプロパティ、少なくとも親クラスに添付するのが最善です。
• より多くのクラスに散在する、より多くのセキュリティ関連のプロパティがあります。これらは、より深く複雑なオブジェクト階層でも使用されますが、基本的にはここで説明した問題に帰着すると思いました。

編集:より良いアイデアが思いつかなかったので、3 番目のソリューションを実装しましたが、プロパティ名に文字列を使用しました。しかし、リストを使用しているときに別の問題に遭遇しました。sec 関連のプロパティを持つタイプの List as プロパティがある場合はどうなりますか? リストに挿入されるすべてのインスタンスに情報を追加できるようにするには、リストがどこにあるかを知る必要があります...

検索中に別の投稿を見つけましたが、basicallay は同じことを求めています: C# - クラスのフィールドに値を割り当てるときに、特定のフィールドに関連付けられたメタデータを追加しますか? 彼は、その種の情報を保持する基本クラスを実装することを提案しています。これは、「通常の」プロパティで機能します。しかし、リストケースではありません。

詳細な説明と例:

「セキュリティ関連」の例は問題を理解するのに役立つと思いましたが、混乱しただけかもしれません。簡単に言うと、クラスの任意のプロパティにメタ情報を添付する必要があります（また、リストに含まれている可能性のあるアイテムにも）。この情報を配置する必要がある場所は、設計時にわかりますが、クラスのインスタンス化に依存します。したがって、誰がクラスをインスタンス化するかは重要です。これが、静的情報を使用できない理由でもあります。次に例を示します。

クラス B のインスタンスを作成するたびに、メタ情報をアタッチする必要があります

InstanceOfB.ThePropertyWithMetadata.MetaProperty

一方、クラス C のインスタンスを作成するときはいつでも、そのプロパティにメタ情報を追加したくありません。そのメタ情報をユーザー インターフェイスに表示し、そのプロパティに関する詳細情報をユーザーに提供したいと考えています。したがって、メタ情報をいつ割り当てるかはわかっていますが、設計時にクラスに入れることはできません。これで明確になることを願っています:-)

1 つのメソッドを定義するインターフェイスがあります。このインターフェイスには、そのインターフェイスを異なる方法で実装する複数のクラスがあります。

例えば：

私のファクトリクラスには、これらのIFステートメントがたくさんあります

新しい条件が発生するたびにファクトリ クラスを変更しないようにする方法はありますか。IJob を実装する新しいクラスを追加するだけでこれを行うことはできませんか?

編集: [私はAntiif キャンペーンの連中が何をしようとしているのかを理解しようとしています]

御時間ありがとうございます...

私はこれら 2 つの質問で立ち往生しており、明確な答えが得られませんでした。誰でも助けることができますか？

1. 構造的 (ウォーター フォールまたは古典的) アプローチとアジャイル (UP オブジェクト指向) アプローチの比較。

2. UML と Rational Rose とは

ありがとう

オブジェクト指向設計は 20 年前からよく知られています。ドメイン固有言語とドメイン駆動設計は、Ruby や Python などの動的言語で普及しています。ドメインが主にオブジェクトで構成されている場合、たとえば、バッジや実績 (Stackoverflow のバッジなど) を付与するサブシステムの場合、バッジは確かにオブジェクトであるため、オブジェクト指向設計とドメイン駆動設計の両方を使用できます。たとえば、Ruby の場合、この機能を実装する 2 つの gem、BadgeableとPaths of Glory があります。. Badgeable は DSL を使用し、Paths of Glory はオブジェクト指向設計に基づいています。オブジェクト指向の分析と設計によるモデリングが適しているのはどのような場合ですか? また、ドメイン固有言語 (ドメイン駆動設計) によるモデリングが適しているのはどのような場合ですか?

私が取り組んでいる組み込みアプリケーションでは、シリアルポートを介して送信するために、いくつかの異なるオブジェクトからのデータをパケット化する必要があることがよくあります。同様に、データはいくつかの異なるオブジェクトに書き込む必要があるシリアルポートに送られます。

互換性の理由から、パケット内のデータの順序付けでは、1つのオブジェクトに関連付けられたすべてのデータをパケット内に連続して配置することはできません。そのため、各オブジェクトのデータなどを簡単にベクトル化して、すべてをパケットに入れることはできません。

パケットクラスが送受信されたパケットを作成/デコードするために使用する非常に多くのゲッター/ミューテーターを使用して、適切な機能を実現できます。しかし、これはあまりエレガントではないようです。

パケットクラスを、データをプル/書き込みするクラスのフレンドにすることはできますが、オブジェクト指向の原則に違反するため、フレンドの使用は避けるように常に言われていました。

理想的には、実際のアプリケーションを処理するクラスは、パケットクラスについて何も知らず（そして、それ専用のゲッター/ミューテーターを提供する必要はありません）、更新の間にパケットが入った場合、単に新しいデータを持ちます。

起動時に関連するメンバー変数への参照またはポインターをパケットクラスに渡すことができるかもしれないと思いましたが、すべてのメンバーが同じサイズではないため、これも注意が必要です。おそらく、サイズ情報も渡すことができますか？パケットクラスがコンストラクターに対して膨大な量の引数を取る必要がないように、メンバーへのvoidポインターとメンバーペアのサイズのリストをベクトル化する方法はありますか？

この問題をどれだけうまく説明したかはわかりませんが、それが役立つ場合は、説明と詳細情報を提供できます。アイデアをありがとうございました。

現在のtxパケットクラスの省略例：

この例にはヘッダーやチェックサムなどは含まれていませんが、頭痛の原因となっているものの基本的な考え方がわかるはずです。

これを解決できるデザインパターンがあるかどうかを確認しようとしています。

プロパティa、b、cを持つ抽象クラスAを作成しました。クラスAを拡張し、さらにプロパティを追加する別のクラスBがあります：x、y、z。次に、Aを拡張してi、j、kを追加する別のクラスCがあります。最後に、BまたはCを作成するインスタンスを決定するファクトリメソッドがあり、それがヘルプが必要な部分です。このファクトリメソッドはどのように、または何を返す必要がありますか：Aのインスタンスを返す場合、どの特定のインスタンスがBまたはCで作成されたかわかりませんか？具体的なインスタンスを作成するには、このファクトリメソッドが必要です。これで、createBやcreateCのような静的メソッドを記述できることがわかりましたが、ここで別のデザインパターンなどのより一般的なソリューションを探しています。

更新：具象クラスを知りたい理由は、このオブジェクトをフロントエンドjspに渡す必要があるためです。そのJSPは、適切なゲッターを呼び出すことができるように、どの特定のクラスがインスタンス化されたかを知る必要があります。

私は、オブジェクト指向設計の原則を使用して次のシナリオをカプセル化するための最良の方法を見つけようとしています。どのタイプのデザインパターンが最適ですか？

以下に非常に基本的なクラス定義を追加しました。基本的に、人はプランとクレジットカードを持っています。人がプランを変更した場合、差額を請求し（プランのコストが多かった場合）、イベントを作成します

コールバックまたはオブザーバーでこれを行うことができ、それが変更されたかどうかを確認しますPlanがPerson、クロスモデルの動作が多い大規模なシステムでは、これは管理できなくなり、状態に影響を与える無関係なコールバックがたくさんあるため、テストが困難になります。

ボードゲームで「動き」をモデル化する良い方法を探しています。プレイヤーに彼らの動きが何であるかを尋ね、彼らに反応させ、そして彼らの動きに基づいてボード上で正しいアクションを実行できるようにしたいと思います。問題は、いくつかのタイプの移動があり、それぞれが独自のデータセットを持っていることです。たとえば、スクラブルでは、単語、その位置と方向（または位置などを含むタイルのセット）を返す単語を再生できますが、タイルを交換することもできます（これには、必要なタイルを返す必要があります）スワップ）またはパス。

同様に、チェスでは、通常、駒を移動します。これにより、駒とその移動先の動きが返されますが、2つの駒とその位置、または側面（キング/クイーン）などを示す城もあります。ピース/位置以外の情報。

プレイヤーがMoveオブジェクトを返すのが最善の方法だと思いますが、他のモデリングの選択肢や提案も受け入れます。

ありがとう！

スキームを仮定すると：

問題は、 内から ParentName を取得することComplexPropertyです。

私が思いついた最善の解決策は、Parent のコンストラクターを使用してプロパティを初期化することですが、これはバグが発生しやすく、別の場所からプロパティを設定すると失敗します。

例えば：

これについてのアイデアはありますか？この種のアーキテクチャのベスト プラクティスはありますか? ComplexPropertyは常に特定のインターフェイス実装の子になるため、リフレクションは実行可能ですが、望ましい解決策ではないことに注意してください。