2013-06-06 3 views
8

В моей библиотеке есть концепция «пользовательских уровней». Я предоставил несколько уровней по умолчанию, но по разным причинам хочу дать пользователю возможность использовать свои собственные уровни.Лучший способ поддержки «Расширяемые перечисления» в аннотациях?

В настоящее время это реализуется как

public interface AdminLevel { 
    public void name(); 
} 

public enum StandardAdminLevels implements AdminLevel { 
    ADMIN, 
    ANONYMOUS 
} 

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

  • Использование AdminLevel в качестве типа - сбой с «недействительный тип для члена аннотаций»
  • Использование строки как типа, но заходящего значение с StandardAdminLevels.ADMIN.name() - сбой с «значением атрибута должно быть константа»
  • Создания StandardAdminLevels окончательного класса, который ничего с государственными статическими последним полем нам не реализовать для каждого из уровней (по существу перечислений) - сбой с„недействительным типом для члена аннотаций“

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

Любые идеи?

+0

Расширяемое перечисление является противоречием в терминах. Вся цель перечислений состоит в том, чтобы определить весь набор и только разрешить их. – Aurand

+0

@Aurand Как волшебные струны или волшебные ints лучше? Перечисления по-прежнему полезны здесь для проверки значений – TheLQ

+0

. Что случилось с наличием одного перечисления со всеми возможными значениями? –

ответ

7

Одна идея: каждый возможный AdminLevel - это собственный класс. Передайте Class этого класса в аннотацию.

public final class Admin implements AdminLevel { ... } 
public final class Anonymous implements AdminLevel { ... } 

@Requires(Admin.class) public void protectedMethod() { ... } 

@interface Requires { 
    Class<? extends AdminLevel> value(); 
} 
+0

Woah, это на самом деле неплохая идея. Классы могут даже реализовать Comparable и, следовательно, быть отсортированным пользователем – TheLQ

+0

Хорошее мышление, но я не уверен, что вижу преимущество над обычными строками. –

+0

@Paul Автоматическая проверка («sadfakjdsf» не является автоматически уровнем администратора) и сортировкой пользователей. Я посмотрю, есть ли другие идеи, но это довольно хорошо – TheLQ

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