对于包含团队、角色和技能的结构建模,是否有设计模式?

我在谷歌上搜索了这个,所以带上一粒盐。我发现了这个 paper 关于角色建模和对象。在第30页有一个角色模式。希望这对你来说不是一场白费力气的追逐。这是总结

角色模式允许您设计一个组件,该组件可以在运行时使用新的 上下文对象,称为角色。组件根据上下文使用角色进行扩展 对象模式。组件对应于decorator的组件,角色对应于 到上下文对象。角色扮演组件的状态集成是通过应用 财产和战略。属性用于定义组件的状态空间,以及 策略用于提供依赖于属性的行为。

听起来您可能会在这里使用复合模式的变体,至少在部分问题上是这样。你可以从作为超类的单元开始,然后你可以把一个团队作为单元的子类。团队是可能包含其他单位的容器。此外,你可以有用户子类单元。因此,您可以编写简单地以单元为目标并以相同的方式对待所有团队和用户的代码。然后,您可以创建一些由其他团队组成的复杂团队。

因此,您可以为您需要的每种类型的用户或团队提供一个类。

如果角色的数量急剧增加,最终导致类过多(类爆炸),那么可以应用decorator模式。因此,可以用另一个具有类似接口但不同(或附加)功能的对象包装(装饰)一个对象。

所以你可以有一个basicuser和一个answerphonedecorator。把任何basicuser对象包装到answerphonedecorator中,您就有了一个可以接听电话的用户。

我没听说过什么,但很简单,可以用多种方法解决。

所以有团队,成员,角色和技能。团队只是成员容器,成员具有角色和技能。

这里还有一个小小的赝品可以告诉你整个想法:

class Team
    container[Member] members

class Member
    container[Role] roles
    container[Skill] skills

然后实例化或子类化角色和技能,这取决于它们是什么类型的东西以及编程语言的功能。

……另一方面,在实践中,让一个团队类类似于角色和技能类——一个成员类的属性可能是有意义的。如果你需要了解某个成员可以访问的内容。

在您的示例中,我至少有TeamMember基类和2个接口(IEMail和iPhone)。任何新角色都将继承自TeamMember类,并根据其功能实现适当的接口…简而言之,角色将实现为一个继承自TeamMember的类,而技能将实现为一个接口。

例如,允许队长打电话。然后我会让TeamLeader类继承TeamMember并实现iPhone接口

RWendi

虽然我相信设计模式是一个很好的工具,但我不认为我会使用任何特定的模式来解决这个问题。相反,我会尝试从另一个角度来接近它。我建议使用一个数据库来存储有关您的团队、团队成员及其角色的数据。现在,数据库并不是我的强项,但我要试一试:
创建一个表以容纳所有团队中的所有团队成员。该表应具有以下属性:姓名、角色、团队、代表成员姓名和角色的技能、成员所属的团队以及成员的技能。
现在,假设您的应用程序中有以下角色:rolea(对于可以接听电话和发送电子邮件的用户)、roleb(只能发送电子邮件)和rolteamleader(例如,可以接听电话、发送电子邮件和参加会议)。 roles表将包含应用程序中的所有角色,属性将是(在本例中):name(角色的名称)、can answer phone(boolean表示具有此角色的用户是否可以接听电话)、can send e-mail(boolean表示他/她是否可以发送电子邮件)等等……
例如,第三个表可以保存应用程序中的所有团队,以及有关他们的各种数据(例如,团队正在处理的项目等等)。
现在,你可以很容易地让团队中的所有成员,他们能做什么,改变他们的角色,看谁是领导者,改变某个角色做什么等等……

我希望这对你有意义。祝你设计应用程序好运!

这取决于你在做什么模特。考虑到你上面的例子,你想找到最适合给定问题的团队成员吗?

如果是这样的话,我建议你这样做: 将角色和技能想象为无向图中的顶点。一个给定的角色(通过一个边缘)与它所能拥有的每一项技能相关联(假设技能是由角色给出的,而不仅仅是基于个人)。现在将所有团队成员连接到他们在团队中的任何角色,并将团队成员连接到适当的团队。

这个图表现在模拟了您的团队、团队成员、他们的角色以及他们应该赋予角色的技能之间的关联。

现在,要将给定的问题映射到团队成员(甚至团队),请将问题与您认为需要的每个不同技能(如电子邮件、数据库、Web UI、Web服务等)连接起来。现在您也可以将问题与这些实体关联起来。

我不会检查你能用它运行的所有类型的报告,但这里有一个简单的报告。如果你想找到一个可以解决这个问题的人(如果他们存在的话),我建议你这样遍历一个图:

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
   }
 }

正如你在这方面所看到的,我对其他海报的图案没有多大用处。如果您试图对域安全性或某种不同的业务逻辑建模。他们的技术很可能是正确的。

顺便说一下,上面的算法不是最优的。

我发现第五章 Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML 讨论如何很好地建立关系模型