Per i metodi che non accedono mai a variabili d'istanza o variabili statiche e agiscono proprio come una funzione (distanziati dal nome) e sono deterministici in base solo agli argomenti di input, voglio chiedere, ci sono qualche considerazione se li cambio tutti in metodo statico?
Continuo a sentire le persone che dicono che il metodo statico è scarso, ma sto cercando un esempio di codice reale nel mio caso precedente.
Il problema con i metodi statici è la mockability e più in generale la sostituibilità. Sebbene esistano strutture di simulazione che ti consentiranno di simulare metodi statici, esiste un supporto più ampio per la simulazione di un metodo non statico ed è semplice farlo da sottoclasse.
Dire che sto testando la classe A che interagisce con la classe B. Se chiama solo membri non statici di B, allora posso iniettare una sostituzione per B che si comporta come ho bisogno, ad esempio per il test. Ma se chiama un membro statico di B, è difficile (a seconda del tuo scherno framework, a volte impossibile) deridere. Quindi devo usare una vera B - o la vera classe B - nel mio test di A; ora ho un test più complicato e uno che sta testando più dell'unità (A) a cui sono interessato. È più fragile e più difficile ragionare che se riesco a prendere in giro il metodo.
Penso che sia la migliore motivazione per evitare metodi statici.
Mi sembra che il metodo statico incoraggi un comportamento del genere. In questo caso abbiamo una classe globale con una funzione statica. Stiamo nascondendo il fatto che Foo dipende da StaticWorker.DoWork() .
Metodo statico
public class Foo
{
public void Bar()
{
StaticWorker.DoWork();
}
}
D'altra parte, i metodi a livello di istanza incoraggiano passare l'oggetto dipendente. Che è meglio che raggiungere un globale.
Metodo di istanza
public class Foo
{
Worker Worker;
public Foo(Worker worker)
{
this.Worker = worker;
}
public void Bar()
{
this.Worker.DoWork();
}
}
Ovviamente potresti passare una funzione, ma mi piace ancora l'astrazione che ottengo con gli oggetti.
Un altro enorme vantaggio dei metodi a livello di istanza è che la classe può implementare un'interfaccia che non è possibile fare per un metodo statico.
Questo è simile all'argomento Singleton. Gli stessi Singleton non causano danni se usati correttamente, ma rendono più facile per le persone chiamare il singleton su tutto il loro codice senza passarlo, creando nuovamente dipendenze invisibili e stato globale.
Ci sono delle eccezioni alla regola. A volte hai un metodo piccolo e leggero. Non cambierà mai, e non è una dipendenza per nient'altro, potrei renderlo statico. Devi usare il tuo miglior giudizio caso per caso, ma direi casi di favore, soprattutto se hai dei dubbi.
Mi sembra che ci siano molti vantaggi nell'usare i metodi di istanza e tutto ciò che devo fare è creare un'istanza di un oggetto. Un piccolo prezzo da pagare per i premi.
Dichiarare le funzioni pure come statiche è corretto secondo me. Sarebbe scomodo richiedere la creazione di un'istanza di un oggetto stateless solo per chiamare una funzione.
Tuttavia esistono casi in cui è necessario che siano in un'istanza dell'oggetto. Ad esempio quando si passa quella funzione a un altro metodo, come si fa con un comparatore in un metodo di ordinamento. Più in generale, quando devi sostituire la tua funzione o un insieme di funzioni con un'altra, hai bisogno di un'istanza.
La cattiva reputazione dei metodi statici deriva da quando vengono utilizzati come sostituti del modello Singleton. Ma in questo caso, c'è uno stato memorizzato in variabili statiche.
Leggi altre domande sui tag object-oriented tdd java design-patterns static-methods