Interface come etichette è una cattiva pratica in Java OO?

Question

Durante l'analisi di alcuni file XML, mi imbatto in una situazione in cui devo usare l'interfaccia come etichette per identificare che determinati tag appartengono a una determinata categoria, ad esempio ho creato un'interfaccia Tag per identificare che queste classi vengono utilizzate per rappresentare i tag xml e ContainableTag per sottolineare che alcuni tag possono essere uno dei tag secondari di alcuni tag.

Quindi mi imbatto in questa pagina: http://xahlee.org/java-a -day / interface.html (cercare la sessione " Interfaccia come etichette "). Dice:

  

L'essenza del problema è che lo è   un pezzo di irrilevanza matematica in   la lingua. Come meccanismo di etichettatura   in una lingua, per il possibile   beneficiare dell'ingegneria del software   prospettiva, quindi non dovrebbe essere   progettato come parte della classe   Interfaccia, dal momento che il concetto di   etichettatura e concetto di programmazione   interfaccia, sono semanticamente diversi.

Quindi l'interfaccia come etichette è necessariamente una cattiva pratica? Come programmatore Java, abbiamo altre alternative?

Answer 1

Le interfacce come marcatori sono state in gran parte sostituite dal meccanismo di annotazione in Java 5 o versioni successive. Ti consentono di aggiungere metadati arbitrari. Se le tue interfacce sono vuote e servono solo a fungere da marcatori di classe, dovresti invece utilizzare le annotazioni.

Answer 2

Sebbene le annotazioni possano fornire un'alternativa a ciò che realizzano le interfacce marker, sono disponibili solo in Java e non si integrano bene con gli IDE: utilizzo anche interfacce marker per taggare concetti correlati nel mio progetto e quindi posso usare il tipo gerarchia del browser per trovare tutti i membri (suppongo che questo sarà presto supportato dai principali IDE per le annotazioni).

Per quanto riguarda l'articolo che menzioni, non vedo il punto nel sostenere che se una classe sintatticamente / strutturalmente "soddisfa" soddisfa ". un'interfaccia, tale interfaccia può / dovrebbe essere applicata automaticamente alla classe (" Qualsiasi classe può dichiararla [RandomAccess] come interfaccia ... "). Questo è un pensiero all'indietro, secondo me.

Direi che i luoghi in cui una tale interfaccia marcatore viene utilizzata in un'istruzione "instanceof", usano la logica invertita, ma fintanto che rimani bloccato in una lingua senza eredità multipla, aspetti e annotazioni, non vedo niente di meglio modo per raggiungere questo obiettivo senza uscire dalla lingua di base.

Si noti inoltre che questo argomento improbabile su un'interfaccia vuota sempre applicabile potrebbe essere applicato anche alle annotazioni.

Answer 3

Le annotazioni non sono necessariamente ciò che desideri. Le interfacce di tagging sono un modo di lavorare una proprietà di un tipo nel tipo stesso. Ad esempio, se stai per iniziare a scrivere un codice simile al seguente:

@interface ContainableTag{}

@ContainableTag public class Foo {}

// ... elsewhere...

/**
 * Adds obj as a child element.
 * @throws IllegalArgumentException if obj is not tagged with 
 *         the ContainableTag annotation.
 */
public void addElement(Object obj){
    if (!obj.getClass().isAnnotationPresent(ContainableTag.class))
        throw new IllegalArgumentException("obj is not a ContainableTag");
    // add the containable tag as an element
}

Quindi considera se davvero non pensi che questo abbia un aspetto migliore:

interface ContainableTag {}

public class Foo implements ContainableTag {}

// ... elsewhere...

public void addElement(ContainableTag ct){
    // add the containable tag as an element
}

Certo, l'interfaccia di tagging non fornisce alcuna informazione su quale comportamento fornisce il tipo stesso, ma non consente ad altri tipi di applicare questa proprietà non comportamentale. Sarei stato sicuramente risparmiato un sacco di fastidiosi bug se ObjectOutputStream avesse un metodo writeObject (serializzabile) anziché writeObject (Object) .

Modifica: ho supporto non insignificante qui.