0

複数の数学ソルバーを使用するゲーム/シミュレーション アプリケーションに取り組んでいます。それぞれに既存のアダプタ クラスがあります。これらのアダプター クラスは、アプリケーションのすべてのレンダリングおよび機能情報を提供します。

大まかに言えば、アダプター オブジェクトを保持してインスタンスを表し、メソッドを呼び出して次のことを実現します。

  • レンダリングデータを生成します。
  • オブジェクトの状態を変更します。それを行うには機能が多すぎます。
  • さまざまな目的でデータ モデル情報を読み取ります。

問題は、これらのクラスが一定期間にわたって成長し続け、あまりにも多くの情報と責任を負うことです。

私の質問は、これらのクラスをより適切に再設計/再構築するにはどうすればよいかということです。私が見るべきデザインパターンはありますか？

編集：リクエストに応じて、アダプタークラスが行うことの広範なリストを以下に示します。

  1. 数学ソルバーに保存されている現在のデータと同期します。

  2. アプリケーションのデータ モデルと同期します。元に戻す/やり直しなどの場合。

  3. オブジェクトの状態を変更する: 形状を変更します。これは最も重要であり、それを実現するために 50 以上のさまざまな機能があります。すべては、パラメータを使用した自己完結型の単一のサービス コールです。ここにインターフェイスとファクトリを挿入しようとしていますが、関数のシグネチャに互換性がありません。

  4. 数学ソルバーのデータ モデル情報を取得します。getChildern などのように

  5. 可視性とその他のグラフィック プロパティを変更します。
4

2 に答える 2

2

使用する原則は、GRASPのInformationExpertです。

[…]InformationExpertの原則を使用して、責任を割り当てる一般的なアプローチは、特定の責任を調べ、それを実行するために必要な情報を決定し、その情報がどこに保存されているかを決定することです。情報専門家は、それを遂行するために必要な最も多くの情報を持ったクラスに責任を負わせることにつながります。[…]

明示的に言及されたことはありませんが、この原則を適用すると、MartinFowlerがリファクタリングの本の「オブジェクト間で機能を移動する」の章で示したパターンを使用することになります。

[…]多くの場合、クラスはあまりにも多くの責任で肥大化します。この場合、Extract Classを使用して、これらの責任の一部を分離します。クラスが無責任になりすぎた場合は、インラインクラスを使用して別のクラスにマージします。別のクラスが使用されている場合は、HideDelegateを使用してこの事実を隠すと役立つことがよくあります。デリゲートクラスを非表示にすると、所有者のインターフェイスが常に変更されることがあります。その場合は、[ミドルマンの削除]を使用する必要があります[…]

于 2013-01-02T12:33:38.000 に答える
1

一般に、単一責任の原則に従って、変更する理由がそれぞれ 1 つだけになるように、クラスを分類します。抽出するクラスのファサードとして「アダプター」をそのままにしておきます。リファクタリングがスムーズになります。

すべてのアダプターに共通する役割のリストを記述しているため、アダプター間でほぼ同じコードが多数ある可能性があります。この演習を進めながら、複数のアダプターから同じ責任を抽出してみて、重複を排除する方法を確認してください。

「Modify Object state」のクラスを抽出することから始めたくなるでしょう。その責任を果たす 50 (!) 以上の関数があるため、可能であれば、おそらくいくつかのクラスに分割する必要があります。これがアダプタ クラスの肥大化の最大の原因である可能性が高いため、これを実行するだけで問題が解決する可能性があります。

ただし、これには多くの作業が必要であり、アダプタ間で抽出されたクラスを再利用する機会が簡単に見つからないほど複雑になる可能性があります。一方、小さな責任を抽出しても、多くのメリットは得られません。真ん中の何かを選んで始めます。

于 2013-01-02T13:06:36.193 に答える