2017-11-01 3 views
-1

私は、再生回数、オーディオ品質、スターレビュー、アルバムアートワークの存在など、いくつかの基準に基づいてアルバムをスコアリングする比較的簡単なアルゴリズムを構築しています。このアルゴリズムに最適なデザインパターンが何であるかを決めるために、私は入力を愛するでしょう。今は、ビルダーがこの問題に最善を尽くしているように感じます。アルバムをスコアリング/ランク付けするためのJavaパターン

  1. サービスによっては、エンドユーザーが包含または除外するためにどの基準を選択することができ得点を使用しています:

    はここにいくつかの詳細です。たとえば、あるサービスでは星のレビューを検討し、別のサービスでは星のレビューに基づいてスコアを付けたくない場合があります。最終的には、彼らが望むが、スコアラーを作るのはユーザーの責任でなければならない。

  2. 条件の入力範囲は、intからStringまで、ブール値およびその他のタイプです。
  3. スコアは個々のアルバムごとに計算されます。他のアルバムはアルバムのスコアに影響しません。
  4. いくつかのベースライン基準を含める必要があります。たとえば、少なくともスコアリング担当者は聴取数とオーディオ品質を使用する必要があります。第1のポイントで参照されるように、これらの最小基準の上に、ユーザは他の基準を含めることができる。 [ALBUM、LISTEN COUNT、音質、STARレビュー、等...]

ビルダーパターンは、それがあろうから、ここでのベストを適用するようだ:

  • アルゴリズムへの入力は、それに付随するデータを持つアルバムですテレスコープを避けながらユーザーが独自のアルゴリズムを構築できるようにします。思考?ビルダーに含めるべき他のパターンがありますか?

  • 答えて

    0

    さまざまな基準に必要なすべてのデータがアルバムデータに含まれ、各基準が全体的なスコアに寄与していると仮定して、各基準をアルバムをスコアに変換するJava関数に変換することをお勧めします。次に、選択したすべての条件に対して、アルバムの条件関数を実行し、個々の結果を単一のスコアにマージします。その後、条件を列挙に変えて、選択した基準をスコアリング関数に簡単に渡すことができます

    各条件が等しくない場合は、重み係数を返すこともできます(例:星のレビューは所与の基準の寄与が(スコア*重み)/重みの合計であるようなスコアを用いてスコアを計算する。

    0

    スコアリング担当者の構成とスコアラーの適用という2つの設計上の問題がある。これらの質問は、いくつかのデザインパターンのための機会です。

    は、スコアラー自身の複雑さに応じて、最初の質問に対する適切な解決策となります。 2番目の質問は、Strategy patternの明確な使用例です(@ V3Vの回答も同様です)。各「得点者」はアルゴリズムです。戦略パターンは、代替可能なアルゴリズムのための設計である。アルゴリズムのベースライン基準は、Template methodを使用して実施することができる。

    関連する問題