2016-02-23 3 views
1

Существует четыре типа пользовательских типов. Администратор, Супермодератор, Модератор и Участник. Администратор может добавлять и удалять все типы пользователей, включая администратора, и может добавлять основные темы, но он не может загружать документы и проект. Супермодератор может добавлять модератора или участника для всех созданных тем. Супермодераторы могут загружать и удалять документы и проекты. Проекты имеют такие виды, как групповой проект, индивидуальный проект, крайний срок. Однако документы имеют такие же типы, как pdf (книга), ppt (слайды), URL-адреса. Модератор может участвовать в других темах и просматривать проекты, связанные с темой. Участник может регистрировать интересующие темы и добавлять проекты.разделение объектов между классами и создание иерархии

Проблема в том, что здесь у меня отсутствует дизайн концепции oop. Я не могу создать иерархию. Мне действительно не нужен полный код просто нужны способы, помогающие решить проблему. Насколько я вижу здесь, есть только отношения между модератором и членом. Я запрограммировал в C. Но, я еще не знаком с ООП. Кстати, я понял логику, связанную с проблемой, но пока не могу писать в концепции ООП. Как это можно решить? Мне кажется, мне нужна иерархия. Наконец, может быть множественный доступ к данным, потому что если член, созданный администратором, он также должен управляться супермодератором, и интерфейс может использоваться из-за добавления и удаления администраторами и супермодераторами.

+0

[композиционно-дизайн- pattern-java] (https://dzone.com/articles/composite-design-pattern-java-0) соответствует вашим требованиям. –

ответ

0

Ваш прецедент не совсем ясен, но если вы пытаетесь моделировать пользователей и их права. Это может быть моя первая итерация:

Вместо того чтобы пытаться покрыть все в иерархии классов, возможно, вы могли бы моделировать разные аспекты разными классами. Я имею в виду: пользователи, права, действия. Пользователь может выглядеть следующим образом:

public interface User { 
    boolean isAllowed(Action action); 
} 

Право на самом деле является предикат, функция Action -> Boolean:

public interface Right<A extends Action> extends Predicate<A> { 
    Class<A> getActionType(); 
} 

Эта вещь имеет метод test(action) то, который возвращает логическое значение, разрешена ли данное действие. Так что с этим все 4 типа пользователей должны расширить эту BaseClass:

public abstract UserWithRights implements User { 
    private final List<Right<?>> rights; 

    private UserWithRights(List<Right<?>> rights) { 
     ... 
    } 

    @Override 
    public boolean test(Action action) { 
     // search for right with same action type and test it 
    } 
} 

Так дело в том, что все пользователи будут иметь список прав, присвоенных. Я сделал список прав неизменными, но вы можете сделать его динамичным, если он вам подходит.

Так admin будет определяться следующим образом:

public class Admin extends UserWithRights { 
    public Admin(...) { 
     super(asList(
     staticRight(AddUser.class, true), 
     staticRight(AddMainTopic.class, true)); 
     ... 
    } 
} 

Это все статические права, потому что они не требуют каких-либо параметров из действия. Есть однако динамические права, подобно moderator разрешено только для просмотра проектов по темам, она назначена:

dynamicRight(ViewProject.class, view -> isAssignedToTopic(view.getTopic())); 

Так в любом случае, это может быть, как можно было бы начать ...

Смежные вопросы