Реализация различных пользовательских типов через классы и интерфейсы в Java - PullRequest
Новая
       27

Реализация различных пользовательских типов через классы и интерфейсы в Java

2 голосов
/ 05 января 2012

Задача
Я довольно новичок в разработке шаблонов и изучаю книгу «Head First Design Patterns». Мне нужно внедрить систему с 3 типами пользователей: участник, модератор, администратор. Модератор может выполнять все, что может член, плюс добавленные вещи, администратор может выполнять все, что может модератор, плюс добавленные вещи. Я сделал базовый набросок того, как это можно реализовать с помощью интерфейсов и классов; будучи неопытным, мне нужен совет от сообщества SO по поводу этого дизайна - будь то слишком раздутый или глупый, или если он нуждается в исправлениях. Поэтому, пожалуйста, потерпите меня.

Возможное решение
Вот интерфейсы: 

public interface AdminBehavior
{
    public addUser();
    public deleteUser();
}

public interface ModeratorBehavior
{
    public blockUser();
    public deletePost();
}

Классы поведения: 

public class AdminBehaviors implements AdminBehavior
{
    public addUser()        {
        ...
    }
    public deleteUser()     {
        ...
    }
}

public class NoAdminBehaviors implements AdminBehavior
{
    public addUser()        {
        ...//cannot do
    }
    public deleteUser()     {
        ...//cannot do
    }
}

+ Same as above done for Moderators...classes ModeratorBehaviors and NoModeratorBehaviors

Фактические пользовательские классы: 

public class Member
{
    protected ModeratorBehavior moderatorBehavior;
    protected AdminBehavior adminBehavior;

    public Member()     {
        moderatorBehavior = new NoModeratorBehavior();
        adminBehavior = new NoAdminBehavior();
    }

    public login()      {
        ...
    }
    public logout()     {
        ...
    }
    public post()       {
        ...
    }
    public comment()        {
        ...
    }

    //Moderator priv'ed actions
    public blockUser()      {
        moderatorBehavior.blockUser();
    }
    public deletePost()     {
        moderatorBehavior.deletePost();
    }

    //Admin priv'ed actions
    public addUser()        {
        adminBehavior.addUser();
    }
    public deleteUser()     {
        adminBehavior.deleteUser();
    }
}

public class Moderator extends Member
{
    public Moderator()  {
        moderatorBehavior = new ModeratorBehavior();
        adminBehavior = new NoAdminBehavior();
    }
}

public class Admin extends Moderator ((or Member?))
{
    public Admin()  {
        moderatorBehavior = new ModeratorBehavior();
        adminBehavior = new AdminBehavior();
    }
}

Лично я чувствую, что это кажется немного преувеличенным или запутанным ... лучшие способы сделать это?

Ответы [ 4 ]

2 голосов
/ 05 января 2012

Мне это очень нравится ... хотя кажется раздутым.

Я бы, наверное, просто использовал наследование. Администратор расширяет Модератор расширяет член реализует UserType.

Интерфейс UserType может определять все ваши методы Член может реализовывать все методы, но без поведения Модератор может наследовать от члена и переопределять методы, для которых требуется поведение Администратор может наследовать от Модератора и переопределять дополнительные методы, требующие поведения для

Думаю, это было бы проще, но менее умно

1 голос
/ 05 января 2012

Если модератор может делать все, что член делает + больше, а администратор может делать то, что делает модератор + больше.

почему бы не иметь интерфейс Member, модератор расширяет его, а Admin расширяет модератор? 

public interface Member {
  void foo();
}

public interface Moderator extends Member {
  void bar();
}

public interface Admin extends Moderator {
  void boo();
}

Я не уверен, что поведение - лучший подход к тому, что вы описали.

0 голосов
/ 05 января 2012

Я думаю, вы можете упростить это, имея интерфейс Member в качестве суперинтерфейса. Интерфейс модератора расширяет интерфейс члена, а администратор расширяет интерфейс модератора. Таким образом, администратор получает все привилегии как участник и модератор. Класс реализации члена Admin расширит интерфейс администратора, который по умолчанию получает все операции от суперинтерфейса. Так же, как и другие классы реализации реализации соответствующего интерфейса. Я не знаю, какой это шаблон, но я чувствую, что выгляжу чистым.

0 голосов
/ 05 января 2012

Хорошо, для начала администратор должен обязательно расширить модератор, поскольку у администратора есть все возможности модераторов, а затем и некоторые.Если интерфейс для модераторов и администраторов не отличается, в этом случае они должны расширять или, по крайней мере, реализовывать поведение в новом элементе (Привилегированный пользователь).Член не должен содержать привилегированные методы, его следует переместить привилегированному пользователю.В представлении обычные пользователи не должны быть в состоянии вызывать какие-либо команды привилегированных пользователей, это может привести к ошибке, потому что у «членов» нет этих методов.

...