2013-06-06 15 views
8

Nella mia biblioteca c'è un concetto di "livelli utente". Ho fornito diversi livelli predefiniti ma per vari motivi voglio dare all'utente la possibilità di utilizzare i propri livelli.Il modo migliore per supportare "enumerazioni estendibili" nelle annotazioni?

momento questa viene effettuata nel modo

public interface AdminLevel { 
    public void name(); 
} 

public enum StandardAdminLevels implements AdminLevel { 
    ADMIN, 
    ANONYMOUS 
} 

Il problema è che l'utente sta andando solitamente essere passando loro livello utente desiderato in un'annotazione. Le cose che mi hanno provato e fallito:

  • Utilizzando AdminLevel come tipo - l'errore "tipo non valido per il membro annotazione"
  • Utilizzando String come tipo, ma impostando il valore con StandardAdminLevels.ADMIN.name() - fallisce con "valore di attributo deve essere costante"
  • Fare StandardAdminLevels una classe finale che non implementa nulla con public static finale campo di per ciascuno dei livelli (essenzialmente un enum) - l'errore 'tipo non valido per il membro annotazione'

c'è qualche altro modo che posso pensare di avere enumerazioni estendibili nelle annotazioni? Sto cercando di restare con le enumerazioni a causa della loro chiarezza e protezione di base contro i valori non validi, ma l'unico altro modo in cui posso pensare sono le costanti String. Il problema che ho è che richiederebbe la verifica ad ogni singolo punto, i livelli utente sono usati, potenzialmente anche nel codice cliente

Qualche idea?

+0

Un enum estendibile è una contraddizione in termini. L'intero scopo dell'enumerazione è definire l'intero set e consentire solo quelli. – Aurand

+0

@Aurand Come sono meglio le stringhe magiche o le magie? Le enumerazioni sono ancora utili qui per la convalida dei valori – TheLQ

+0

Cosa c'è di sbagliato nell'avere un enum con tutti i valori possibili? –

risposta

7

Un'idea: ogni AdminLevel possibile è la sua classe. Passa il Class di quella classe all'annotazione.

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, in realtà non è una cattiva idea. Le classi potrebbero anche implementare Comparable e quindi essere user sortable – TheLQ

+0

Buon pensiero, ma non sono sicuro di vedere il vantaggio rispetto alle semplici stringhe. –

+0

@Paul Convalida automatica ("sadfakjdsf" non è automaticamente un livello di amministrazione) e personalizzazione dell'utente. Vedrò se ci sono altre idee, ma questa è una buona cosa – TheLQ

Problemi correlati