チームで役割を果たし、スキルが割り当てられたユーザーで構成されるチームが存在するシステムをモデル化する必要があります。
つまり、チーム A の 5 人のメンバーで、1 人がチーム リーダーの役割を果たし、全員が電子メールへの返信の役割を果たしますが、一部のメンバーは電話に応答する特別なスキルを持っています。
これをどのようにモデル化するのが最善かを判断しようとしています。
この問題は以前に解決されているはずです。これをモデル化する方法に関する適切なリソースはありますか?
編集: 特定のチームに属している、特定の役割を果たしている、または特定のスキルが割り当てられているなどの理由で、ユーザーが何を許可されているかを判断する必要があります。
私はこれをグーグルで検索したので、それを一粒の塩で取ってください。Role Modeling and Objects に関するこの論文を見つけました。30ページにロールパターンがあります。願わくば、これがあなたにとって野蛮な追跡ではないことを願っています。まとめはこちら
Role パターンを使用すると、実行時に Roles と呼ばれる新しい Context オブジェクトを使用して拡張できる Component を設計できます。Component は Context Object パターンに従ってロールで拡張されます。Component は Decorator の Component に対応し、Role は Context Object に対応します。ロールプレイング コンポーネントの状態統合は、プロパティと戦略を適用することによって達成されます。Property は Component の状態空間を定義するために使用され、Strategy は Property 依存の動作を提供するために使用されます。
少なくとも問題の一部については、ここで複合パターンのバリエーションを使用できるようです。スーパークラスとして機能するユニットから始めて、ユニットのサブクラスとしてチームを持つことができます。チームは、他のユニットを含むコンテナです。さらに、User サブクラス Unit を持つことができます。したがって、単にユニットを対象とするコードを記述し、すべてのチームとユーザーを同じように扱うことができます。その後、他のチームで構成される複雑なチームを作成できる場合があります。
したがって、必要なユーザーのタイプまたはチームのタイプごとにクラスを提供できます。
ロールの数が劇的に増加し、最終的にクラスが多すぎる (クラス爆発) 場合は、Decorator パターンを適用できます。このように、オブジェクトを別のオブジェクトでラップ (装飾) し、同様のインターフェイスを備えていますが、異なる (または追加の) 機能を備えています。
したがって、BasicUser と AnswerPhoneDecorator を持つことができます。BasicUser オブジェクトを AnswerPhoneDecorator でラップすると、電話に応答できるユーザーができます。
実際に聞いたことはありませんが、さまざまな方法で解決できるほど簡単です。
チーム、メンバー、役割、スキルがあります。チームは単なるメンバーコンテナであり、メンバーには役割とスキルがあります。
全体のアイデアを提供するための小さな疑似コードを次に示します。
class Team
container[Member] members
class Member
container[Role] roles
container[Skill] skills
次に、ロールとスキルの種類とプログラミング言語の機能に応じて、ロールとスキルをインスタンス化またはサブクラス化します。
..一方、実際には、役割とスキルのクラスに似たチームのクラスをメンバーのクラスのプロパティにすることが理にかなっている場合があります。あるメンバーが何にアクセスできるかなどを調べる必要がある場合。
何をモデル化するかによります。上記の例から、特定の問題に最も適したチームメンバーを見つけたいですか?
その場合は、次のようなことをお勧めします。無向グラフの頂点としての役割とスキルを想像してください。与えられた役割は、(エッジを介して) それが可能な各スキルにリンクされています (スキルは役割によって与えられ、個人だけに基づくものではないと仮定します)。ここで、すべてのチーム メンバーをチームでの役割に関連付け、チーム メンバーを適切なチームに関連付けます。
このグラフは、チーム、チーム メンバー、彼らの役割、および彼らが彼らの役割に与えるべきスキルの間の関連付けをモデル化します。
与えられた問題をチーム メンバー (またはチーム) にマッピングするには、問題を取り上げて、必要と思われるさまざまなスキル (電子メール、DB、Web UI、Web サービスなど) のそれぞれに関連付けます。これらのエンティティにも問題を関連付けることができるようになりました。
これで実行できるすべてのタイプのレポートについては説明しませんが、簡単なものを次に示します。その問題を解決できる人物を 1 人 (存在する場合) 見つけたい場合は、次のようなグラフ トラバーサルをお勧めします。
class Problem
{
find_problem_solvers()
{
var problem_solvers = null
for each (skill in skills_required)
{
var possible_problem_solvers = skill.find_problem_solvers()
if(problem_solvers == null)
{
problem_solvers = new list().add_range(possible_problem_solvers)
}
else
{
for each problem_solver in problem_solvers:
{
if(problem_solver not in possible_problem_solvers)
problem_solvers.remove(problem_solver)
}
}
//No point continuing if we eliminated everyone!
if(problem_solvers is empty) break;
}
return problem_solvers
}
}
この点でわかるように、他のポスターのパターンはあまり役に立ちません。ドメイン セキュリティまたは何らかの種類の別のビジネス ロジックをモデル化しようとしている場合。彼らの技術は正しいものである可能性が非常に高い.
ところで、上記のアルゴリズムは最適ではないことに注意してください。
あなたの例では、少なくとも TeamMember BaseClass と 2 つのインターフェイス (iEmail と iPhone) があります。新しいロールはすべて TeamMember クラスから継承され、その機能に応じて適切なインターフェイスが実装されます。要するに、ロールは TeamMember を継承するクラスとして実装され、スキルはインターフェイスとして実装されます。
たとえば、チーム リーダーは電話をかけることができます。次に、TeamLeader クラスが TeamMember から継承し、iPhone インターフェイスを実装するようにします。
デザイン パターンは優れたツールであると信じていますが、この問題に特定のパターンを使用するとは思いません。むしろ、別の角度からアプローチしてみたいと思います。私が提案するのは、チーム、チームメンバー、およびその役割に関するデータを保存するデータベースを使用することです。さて、データベースは私の得意分野ではありませんが、試してみます
。すべてのチームのすべてのチーム メンバーを保持するテーブルを作成します。テーブルには、名前、役割、チーム、メンバーの名前と役割、メンバーが所属するチーム、およびスキルをそれぞれ表すスキルがあります。
ここで、アプリに次の役割があるとします: RoleA (電話に応答して電子メールを送信できるユーザー)、役割 B (電子メールの送信のみが可能)、および役割 TeamLeader (電話に応答し、電子メールを送信できる)たとえば、ロール テーブルにはアプリ内のすべてのロールが保持され、属性は (この場合)、name (ロールの名前)、canAnswerPhone (このロールを持つユーザーが応答できるかどうかを示すブール値) になります。電話)、電子メールを送信できます (彼/彼女が電子メールを送信できるかどうかを示すブール値) など...
3 番目のテーブルは、たとえば、アプリ内のすべてのチームと、それらに関するさまざまなデータを保持できます (チームが取り組んでいるプロジェクトなど....)
これで、チーム内のすべてのメンバーを簡単に取得し、メンバーができること、役割の変更、リーダーが誰であるかの確認、特定の役割の役割の変更を行うことができます。等々...
これがあなたにとって理にかなっていることを願っています。アプリの設計を頑張ってください!