Sono protetti i metodi di auto-fusione Ok?

Question

Sono protetti i metodi di auto-fusione Ok?

#1 da (1 voti)

1

Spesso ho delle superclassi che contengono una forma più astratta di una classe come variabile membro rispetto alla mia esigenza di sottoclassi. Trovo il mio codice sparpagliato ((ClassName)variableName).methodName() . Il modo migliore per risolvere questo problema è creare un metodo protetto / privato chiamato qualcosa come getVariableNameAsClass() ? Non è molto più breve nelle lettere, ma un IDE può farlo molto più velocemente di manovrare con i tasti per aggiungere tra parentesi. O c'è una soluzione migliore?

Il motivo per cui ho bisogno di trasmettere è perché tutte le sottoclassi di Line usano una classe Output , quindi inserisco i getter e i setter che si riferiscono alla classe Output nella classe base. Il problema è che utilizza AudioLine e AudioOutput e deve definire metodi aggiuntivi che utilizzano le funzionalità più specifiche.

Quindi, ecco il mio intero design di classe: ho una classe Line con due sottoclassi, VideoLine e AudioLine , che delegano alcune delle loro funzionalità a una classe Output interna . Output class ha una sottoclasse AudioOutput e VideoOutput . Ho definito tutte le funzionalità per la classe Line che si basa solo sui metodi della classe Output all'interno della classe Line , in conformità con DRY. Line 's AudioLine e VideoLine entrambi deligano funzionalità aggiuntive a AudioOutput e VideoOutput . Dal momento che entrambi impostano la variabile protetta Output nei loro costruttori (e quindi CONOSCONO quale sottoclasse contiene), è sembrato avere senso scriverlo.

programming-practices java

posta sinθ 06.08.2013 - 21:03

fonte

1 risposta

Leggi altre domande sui tag programming-practices java

Permutare una lista di numeri premendo e scoppiando in una pila Ciclo di gioco Android in thread separati

score 1 · Answer 1

La dichiarazione di un campo Output protetto su Line implica che qualsiasi implementazione di Output può essere utilizzata con qualsiasi implementazione di Line . Nel tuo caso questo non è vero, e le repliche ripetute sono un buon indicatore del fatto che la struttura della tua classe non è sicura dal punto di vista del tipo.

(Immagina se, a causa di una modifica o di un bug, Line sostituisse VideoOutput richiesta da VideoLine con AudioOutput - non sapresti fino a quando non si blocca)

Raccomandazione:

Sposta il campo di output nelle sottoclassi. Due opzioni (preferisco la prima, ma considerate entrambe valide):

1) Rendi astratti i metodi Output -dependent e fornisci metodi di utilità per fare il lavoro

public abstract class Line{
    public abstract void doThing();
    protected final void doThing(Output output){
        ...
    }
}
public class VideoLine extends Line{
    private VideoOutput output;
    public void doThing(){
        super.doThing(output);
    }
}

2) Fornire un metodo getOutput() per la super-classe da utilizzare.

public abstract class Line{
    public abstract Output getOutput();
    public void doThing(){
        Output output = getOutput();
        ...
    }
}
public class VideoLine extends Line{
    private VideoOutput output;
    protected Output getOutput(){
        return output;
    }
}