4

以下で説明するビジネス要件に対応するためにここで使用できる最適な設計パターンは何ですか?

Car、Boat、およびPlaneなどのさまざまな車両に最小限の変更で簡単に使用できる単一のダッシュボードを作成するというビジネス要件があるとします。基礎となるシステム (たとえば、速度、バッテリー、深度、高度、熱、および方向転換、加速、開始、停止、ブレーキなどの機能に関する情報を収集するため)。ダッシュボードには、基礎となるハードウェアと再び通信する何かと通信するゲージなどが付属する必要があります

明らかな解決策は、問題をコンポーネントに分解することです (以下を参照)。これにより、車両を切り替えるときに最小限の変更しか必要ありません。次のソリューションでは、CentralController の具体的な実装のみが車両ごとに異なる必要がありますが、車内で通信するコンポーネントが何百もあり、それらすべてのタイプをアプリケーション関連のタイプにマッピングするとどうなるでしょうか。 HeatGauge には、内部、外部、およびエンジンからの情報が含まれている可能性があります。したがって、車両のさまざまなコンポーネントについて話しているため、車両ごとに異なる可能性があります。ここでデータ マッピングに対処するためのベスト プラクティスは何ですか?

  • ゲージ付きパネル
  • セントラルコントローラー{取得/設定}。CentralControllerImpl
  • 車両およびその部品

つまり、要約すると次のようになります。

複数の複雑な API の上に単純化された API を作成するための設計パターンは何ですか?

質問が漠然としていると思う人もいるので、ここに本当の問題を投稿します

私は、何百もの種類のセンサーとコントロールを制御する非常に複雑なハードウェアの平和と対話するアプリに取り組んできました。私が取り組んでいるアプリは、その部分を担当する人間の役割に関連するいくつかの機能のみを公開しています。

ハードウェアは、操作する情報の非常に複雑で大規模なデータベースであることがわかります。私が取り組んでいるアプリは、ほんの少しの情報しか公開していません。ドメイン オブジェクトの場合、実際にマッピングを行うコンポーネントは、将来のアプリケーションで活用できるように汎用化されています。

皆さんから知りたいのは、作業が簡単で必要に応じて拡張できる汎用コンポーネントを作成するために使用できる、最適な設計パターンは何ですか?

たとえば、ビジター + MVC が最も明白です

4

3 に答える 3

2

あなたの要件は、単一のパターンには広すぎます。ビジター、MVC、およびファサードはすべて設計全体に関与している可能性がありますが、システムをはるかに高度で複雑なレベルで記述しています。パターンは、一連の一般的な動作を記述し、コミュニケーションを促進するのに役立ちますが、パターンを使用するアプローチが「特効薬を探している」というものである場合、パターンが不当な責任を負うことになり、その努力は欲求不満と失望につながります。

個々の要素をフレームワークに簡単に統合できる一連のパターンを使用してモジュールが連携する設計は、一般的なツールボックスからのコンポーネントの表示を提供し、実装される特定のユース ケースに合わせてカスタマイズされます。ダッシュボードとの類似性は、有用な設計アプローチであるため、出発点として何度も使用されてきました。

例えば、

  • ダッシュボード: ディスプレイにFacadeを使用してゲージを表示するためのフレームワーク、コントロール/ゲージの種類にインターフェイスを提供するためのフロント コントローラー、および ゲージを調整する必要がある場合には Blackboardを使用できます。
  • ゲージ:コンポーネントのフレームワークを提供するのに役立つモジュール、一般的なコールバック動作が必要な場合はビジター、非同期通信が必要な場合はオブザーバーまたはパブリッシュ/サブスクライブ、時間の経過とともに保持する必要がある表示要素の場合は可能性としての状態。
于 2012-08-08T14:04:11.827 に答える
1

クラスのデータと動作に違いがない場合、なぜ異なるクラスを作成する必要があるのでしょうか? たぶん、単一のクラスを作成するのに十分でしょう: Vehicle ? 要件に複雑な問題はないので、パターンは必要ないようです。

于 2012-08-08T13:15:52.263 に答える
0

Builder設計パターンを調べて、それをBridgeと組み合わせることをお勧めします。

于 2012-08-08T12:58:20.077 に答える