Какой шаблон проектирования следует использовать для моделирования отношений между человеком и ролью?

Question

Я просто не мог понять, какой шаблон дизайна мне здесь выбрать.Скажем, у меня есть такой класс:

class Person

String role;

public void takeRole(String role) {
  this.role = role;
}

public void do() {

  switch(role)

    case a:
      do this and that;
      this.role = b;

    case b:
      do this and that;

    case c:
      do this and that;
      this.role=a;

    ....

Короче говоря, у Person есть роли, и метод do () зависит от его роли.В некоторых случаях ему, возможно, придется поменяться ролями.Я думаю, что do () следует абстрагировать (тем более, что в будущем могут быть определены другие роли) --- но как?Должен ли быть ролевый класс?

Буду признателен за любую помощь.

Редактировать:

Спасибо, что уделили нам время, люди.Я хотел бы добавить еще одну вещь.Я действительно думал (по крайней мере, как идея) о многих из предложенных решений.Вот мои трудности: если я подкласс класса Person (например, PersonTypeA, personTypeB и т. Д., И назначаю каждую конкретную роль для соответствующего типа человека, то у меня возникают трудности при переключении ролей (например, инженер становится бухгалтером!--- Странно, если не сказать больше.

С другой стороны, если я создаю классы для каждой роли, то (1) роль не ощущается как объект, потому что (по крайней мере, в моем случае)Роль не имеет атрибутов, а только метод (ы). Следовательно, role_A_1 ничем не отличается от role_A_2. Но для каждого человека мне придется создать новый объект роли - даже если они оба имеют одинаковую роль.

Я не уверен, дал ли я ясность, и не уверен, что мои пункты имеют смысл.

Answer 1

Не в шаблонной форме, а более логично:

Вместо того, чтобы играть огромную роль, если это так, сделайте это, в противном случае, если это утверждение, какой-то класс Role сметод DoThis () будет проще.

У человека есть роль.Человек может DoThis () и что Роль также может DoThis ().

Вместо того, чтобы Человек говорил, что он делает в соответствии с Ролью, Роль говорит, что он может сделать.

Answer 2

Я также вижу здесь шаблон состояния . Например, вы можете создать что-то вроде:

interface Role {
    public void doRole(Context context);
}

class RoleA implements Role {
    public void doRole(Context context) {
        // do this and that
        context.setRole(new RoleB());
    }
}

class RoleB implements Role {
    public void doRole(Context context) {
        // do that and this
        context.setRole(new RoleA());
    }
}

class Context {
    private Role _role;

    public Context() {
        // set initial role
        setRole(new RoleA());
    }

    public void setRole(Role newRole) { _role = newRole; }

    public doSomething() {
        _role.doRole(this);
    }
}

В этом примере вы делегируете поведение объекта Context, запрашивая его назначенный в данный момент объект Role. Сами конкретные роли имеют методы, которые определяют переходы между ролями. По сути, здесь возникает простой конечный автомат, в котором конкретные Role s являются узлами и вызывают setRole() ребра.

Answer 3

Я обнаружил, что общение с людьми, компаниями и ролями повторяется снова и снова.Книга паттернов анализа Мартина Фаулера (с Уордом Каннингемом и Ральфом Джексоном) содержит подробное обсуждение, которое стоит прочитать подробно.

Онлайн-версия главы «Работа с ролями» (или краткое изложение, я думаюне иметь книги под рукой) можно найти как: http://martinfowler.com/apsupp/roles.pdf.

На сайте Мартина Фаулера также есть целый раздел, посвященный шаблонам анализа: http://martinfowler.com/apsupp/roles.pdf

Answer 4

Возможно, вы захотите взглянуть на доменно-нейтральный компонент Coad:

http://www.petercoad.com/download/bookpdfs/jmcuch01.pdf

Это имеет людей с несколькими ролями, но продвигает вещи немного дальше, включая события (моменты-интервалы),Он также много говорит о цветном моделировании, что интересно, но не позволяйте этому оттолкнуть вас - я думаю, что идеи довольно здравые.

Ян.

Answer 5

Я бы сказал, что роль имеет человека. У меня был бы Role-интерфейс, конкретная реализация которого обернула бы Person и украсила бы его новыми необходимыми мне возможностями.

public interface Role
{
    Person getPerson();
    void action(); // might need more here
};

public class Person
{
   // whatever fields you need
}

public class Admin
{
    private Person person;

    public Admin(Person p) { this.person = person; }

    public void action() { } // some some admin stuff.
}

Answer 6

Я бы сделал интерфейс с методом do, например

interface Action {
    void do()
}

А затем определите Map<String, Action>, чтобы для данной роли связанное действие могло быть получено с помощью actionMap.get(role). Затем просто наберите do() для действия actionMap.get(role).do()

Answer 7

Взгляните на Замена условного диспетчера командой