Progettazione del metodo statico rispetto all'oggetto

Question

Come illustrato di seguito, esistono due modi semplici per eseguire una copiatrice di flussi (barra che introduce Apache Commons o simili). Quale dovrei andare a fare, e perché?

public class StreamCopier { 
private int bufferSize; 

public StreamCopier() { 
    this(4096); 
} 

public StreamCopier(int bufferSize) { 
    this.bufferSize = bufferSize; 
} 

public long copy(InputStream in , OutputStream out) throws IOException{ 
    byte[] buffer = new byte[bufferSize]; 
    int bytesRead; 
    long totalBytes = 0; 
    while((bytesRead= in.read(buffer)) != -1) { 
     out.write(buffer,0,bytesRead); 
     totalBytes += bytesRead; 
    } 

    return totalBytes; 
} 
} 

vs

public class StreamCopier { 

public static long copy(InputStream in , OutputStream out) 
    throws IOException { 
    return this.copy(in,out,4096); 
} 

public static long copy(InputStream in , OutputStream out,int bufferSize) 
    throws IOException { 
    byte[] buffer = new byte[bufferSize]; 
    int bytesRead; 
    long totalBytes = 0; 
    while ((bytesRead= in.read(buffer)) != -1) { 
     out.write(buffer,0,bytesRead); 
     totalBytes += bytesRead; 
    } 

    return totalBytes; 
} 
} 

Answer 1

mi piacerebbe andare con la versione non-statico (esempio), e l'offerta ai consumatori come una dipendenza esplicita con un setter:

• beffardo fuori per il test delle unità è quindi banale, così le prove di i consumatori non sono accoppiati all'attuazione;
• lo swapping delle funzionalità è semplice, ad es .: utilizzando una sottoclasse;
• funziona bene con i sistemi di iniezione dipendenti.

Modifica

In risposta a una (utile!) Commento di "come fa questo aiuto beffardo?", Ecco come potrebbe funzionare:.

class ThingThatUsesStreamCopier { 

    // our copier instance. set in constructor, but might equally use 
    // a setter for this: 
    private StreamCopier copier; 

    public ThingThatUsesStreamCopier(StreamCopier copier) { 
     this.copier = copier; 
    } 

    public void makeCopy(Stream in, Stream out) { 
     // probably something a little less trivial... 
     copier.copy(in, out); 
    } 
} 

Quando vengo a testare ThingThatUsesStreamCopier, posso creare una versione mock object di un StreamCopier e creare un'istanza della ThingThatUsesStreamCopier utilizzando questo finto

In questo modo, ho piena controllo sul comportamento del mio simulato, quindi il mio test è disaccoppiato da qualsiasi reale implementazione di StreamCopier. Sto solo testando il consumatore, non il consumatore più il consumato.

Answer 2

vorrei andare per la versione statica perché non c'è stato.

In genere non esiste un punto in un oggetto stateless a meno che non sia necessario per scopi di ereditarietà (metodi virtuali).

Se è probabile che gli utenti vogliano prendere in giro la funzionalità, preferirei un'interfaccia su un'implementazione concreta - l'implementatore dell'interfaccia non potrebbe essere statico, quindi in questo caso dovresti utilizzare un oggetto istanziato.

Modifica: Un paio di anni più tardi e ora desidero incolpare il mio ex autore per suggerire la versione statica. Vorrei andare per la versione di istanza senza alcuna esitazione di sorta in questi giorni.

Answer 3

Dato che non vedo grandi differenze nelle prestazioni, penso che questa sia semplicemente una questione di praticità e secondo me il metodo statico è molto più pratico ;-).

Answer 4

Vorrei andare con la versione statica.

Non è necessario un oggetto poiché non si sta memorizzando lo stato, quindi perché creare un chiamante per creare un oggetto solo per chiamare un metodo.

Answer 5

Tutto dipende dal modello di utilizzo. Forse hai solo bisogno di copiare qualcosa da un InputStream a un OutputStream di tanto in tanto? Allora probabilmente non importa. Tuttavia, se si sta eseguendo molta copia in vari ambienti (flussi di rete, LAN e WAN, copia di file sul disco locale) si potrebbe stare meglio quando si ha la possibilità di selezionare la dimensione del buffer utilizzato per la copia.

Quindi, perché limitarsi a un solo metodo? Implementalo con metodi object e un costruttore che prende una dimensione del buffer (usata per le tue esigenze variabili), e magari aggiungi un metodo statico per ottenere un'istanza pseudo-singleton che usa alcune dimensioni del buffer di default (che è usata per la copia casuale ogni ora e poi).

Answer 6

Ci sarà una minima differenza in overhead (la statica sarà assegnato una volta vs allocati su base di istanza) soprattutto dato che lo stato è costituito da un singolo int. Generalmente raramente vado per le classi statiche perché rendono difficili i test unitari. C'è poco overhead nel rendere le classi basate su istanze piuttosto che statiche (un'assegnazione, azzerando la memoria e chiamando il costruttore - che sono tutte v operazioni rapide) e a causa dell'incapacità di deridere la statica vedo poco beneficio.

Tra le altre cose la classe statica può anche aumentare notevolmente l'accoppiamento; una classe statica può essere referenziata da qualsiasi luogo purché venga fatto riferimento al riferimento all'assembly. Quando si tratta di refactoring, ciò può portare a problemi (ad esempio, i riferimenti staitc internamente vengono trascinati nel grafico delle dipendenze, ecc.).

Answer 7

public static long copy 

Non hai bisogno di un esempio per eseguire il metodo perché non stai memorizzazione dello stato, e non si ha intenzione di avere sottoclassi di questo.

Vorrei solo aggiungere la parola chiave final.

I metodi ausiliari come questo sono buoni utilizzi dei metodi di classe rispetto ai metodi di istanza.

Answer 8

non importa cosa usare in questo momento, ma si potrebbe pensare, cosa avresti bisogno in futuro. Forse hai qualche piano per estendere le operazioni di buffer o qualcosa del genere. Sceglierei metodi non statici

Answer 9

Dipenderà dall'utilizzo. Il codice che chiama la copia sa qual è la dimensione del buffer appropriata? Potrebbe essere che la decisione sia stata presa al di fuori di tale codice e un'istanza StreamCopier è una cosa migliore da passare come parametro rispetto a una dimensione del buffer (ad esempio se si scopre che in un momento successivo era necessario un parametro aggiuntivo no sarebbero necessarie modifiche al codice)

Answer 10

Se si utilizza la statica, è necessario evitare i nomi WET.

WET è sinonimo di tutto ciò di scrittura per due volte, in tal modo, invece di StreamCopier.copy chiamano

Copy.stream(in,out) 

in questo modo il codice legge più come l'inglese.

Answer 11

Il metodo statico indica la codifica di una classe concreta, non un'interfaccia. Significa un accoppiamento più stretto e rende più difficile l'Unit Testing. È qui che la regola "contiene stato" cade.

Answer 12

Quando si utente Metodo statico, si chiami in qualsiasi momento che restituirà lo stesso oggetto, ma si crea new A() creerà nuovo oggetto quando si lavora con esso