Non usare "statico" in C #?

Ho presentato una domanda che ho scritto ad alcuni altri architetti per la revisione del codice. Uno di loro quasi immediatamente mi ha risposto e ha detto "Non usare" statico ". Non puoi scrivere test automatici con classi e metodi statici." Statico "è da evitare".

Ho controllato e 1/4 delle mie classi sono contrassegnate come "statiche". Uso statico quando non ho intenzione di creare un'istanza di una classe perché la classe è una singola classe globale utilizzata in tutto il codice.

Ha continuato a menzionare qualcosa che coinvolge derisione, tecniche IOC / DI che non possono essere utilizzate con codice statico. Dice che è un peccato che le librerie di terze parti siano statiche a causa della loro non testabilità.

Questo altro architetto è corretto?

aggiornamento: ecco un esempio:

APIManager: questa classe mantiene i dizionari delle API di terze parti che sto chiamando insieme al prossimo tempo consentito. Impone limiti di utilizzo dell'API che molte terze parti hanno nei loro termini di servizio. Lo uso ovunque sto chiamando un servizio di terze parti chiamando Thread.Sleep (APIManager.GetWait ("ProviderXYZ")); prima di effettuare la chiamata. Tutto qui è thread-safe e funziona benissimo con il TPL in C #.

Dipende dal fatto che le classi statiche mantengano lo stato o meno. Personalmente, non ho alcun problema con le funzioni stateless raggruppate in una classe statica.

È troppo generale al riguardo. Ha ragione, ostacola i test. Tuttavia, staticclassi e metodi hanno il loro posto e dipende molto dal contesto. Senza esempi di codice non puoi davvero dirlo.

Uso statico quando non ho intenzione di creare un'istanza di una classe perché la classe è una singola classe globale utilizzata in tutto il codice.

Questo può essere un grave odore di codice. Per cosa stai usando le lezioni? Conservare i dati? Per accedere a un database? Quindi ha ragione. In questo caso dovresti esaminare l'iniezione di dipendenza, poiché una tale classe statica è effettivamente un singleton implicito.

Se li stai usando per metodi di estensione o helper che non cambiano lo stato e operano solo sui parametri che fornisci, quelli di solito vanno bene.

Ho controllato e 1/4 delle mie classi sono contrassegnate come "statiche". Uso statico quando non ho intenzione di creare un'istanza di una classe perché la classe è una singola classe globale utilizzata in tutto il codice.

La cosa migliore da fare è provare e testare l'unità il tuo codice. Prova a progettare test ripetibili, indipendenti, semplici e prova solo un metodo alla volta. Prova a eseguire i test in un ordine casuale diverso. Riesci a ottenere una build "verde" stabile?

Se sì, questo è un punto valido per difendere il tuo codice. Se, tuttavia, hai difficoltà, forse dovresti scegliere metodi basati su istanze.

Le risposte già pubblicate coprono molti punti davvero positivi, ma ce n'è uno che sembra mancare:

I campi statici non vengono mai raccolti.

Questo è molto importante se si dispone di un'app con molti vincoli di memoria e questo modello può essere molto comune quando le persone tentano di implementare una cache.

Le funzioni statiche non sono altrettanto brutte, ma tutti gli altri hanno già affrontato questo argomento in modo sufficientemente dettagliato.

Uno dei vantaggi che si ottengono da IoC / DI è che la maggior parte delle interazioni tra le classi sono negoziate tra le interfacce. Ciò semplifica il test delle unità perché le interfacce possono essere derise automaticamente o semi-automaticamente, e quindi ciascuna delle parti può essere testata per input e output. Inoltre, al di là della testabilità, mettere interfacce tra tutto ciò ti consente di avere il codice più modulare possibile: puoi facilmente sostituire un'implementazione senza troppe preoccupazioni che stai rovinando le dipendenze.

Poiché C # non ha metaclassi, una classe non può implementare un'interfaccia usando funzioni statiche, quindi le funzioni statiche delle classi finiscono per rovinare qualsiasi sforzo per implementare un modello a oggetti IoC / DI puro. Vale a dire, non è possibile creare una simulazione per testarli e è necessario creare dipendenze reali.

Se la tua azienda / progetto è investito molto nel fare l'IoC, questo ovviamente è una preoccupazione ragionevole e il dolore che stai attraversando è per il guadagno di tutti. Dal punto di vista architettonico, tuttavia, personalmente non penso che nessun modello debba essere seguito alla tomba. Ci sono alcune cose che hanno senso implementare usando metodi statici - la strategia di progettazione singleton, per esempio. Sono meno propenso alle classi statiche perché penso che tendano a perdere i vantaggi di OO, ma ci sono momenti in cui una classe di libreria è probabilmente un'espressione più naturale di qualcosa di un motore.

Commenter mi ricorda i metodi di estensione, che ovviamente devono essere in classi statiche in C #. Questo è legittimo ed è un esempio di come l'IoC puro non funzioni molto bene in C #, almeno se stai cercando di sfruttare l'ampiezza della lingua.

Le classi statiche sono talvolta utilizzate in modo improprio e dovrebbero essere:

• un singleton (dove la classe non statica ha un membro statico e una variabile di istanza statica pubblica per recuperarla / crearla una sola volta.
• un metodo in un'altra classe (dove lo stato conta). Se hai un membro che non utilizza dati da quella classe, probabilmente non dovrebbe far parte di quella classe.

Potrebbe anche essere una cosiddetta funzione "utility" e parte di una classe di utility. Le classi di utilità sono classi che contengono solo metodi statici e fungono da funzioni di supporto senza alcun contesto.

I metodi statici vanno bene e hanno un posto legittimo nella programmazione. Sembra che il tuo architetto abbia un framework di test che non supporta completamente i metodi statici. Se il tuo codice fa parte di un progetto più grande, è importante rispettare le linee guida degli architetti. Tuttavia, non lasciare che questo progetto ti scoraggi dall'uso di metodi statici quando è appropriato farlo.

Ho usato proprietà statiche per cose comuni a tutte le istanze di una classe. E ho usato metodi statici per ottenere gruppi di oggetti di classe. Non sono affatto un esperto, ma finora ha funzionato per me.

Esempio di PHP:

class vendorData {
  private static $data_table = 'vendor_data'; // static property
  private $id; // instance property
  private $name; // instance property

  public function __construct($vendor_id) {
    if(!self::validId($vendor_id) ) { // static method
      return false; // id doesn't exist
    }
    $this->id = $vendor_id; // id has been validated
    $this->getProperties(); // object method
  }

  private static function validId($vendor_id) {
    // send db query to find if the id exists
    // return true/false;
  }

  private function getProperties() { // object method
    $sql = "SELECT * FROM `{self::$data_table}` // using static property
        WHERE `id` = {$this->id}"; // using object instance property
    // get resultset
    foreach($result as $property => $value) {
      $this->$property = $value; // object instance properties all set
    }
  }

  // and here
  public static function getBy($property,$value) { // static method to return object array
    $sql = "SELECT `id` FROM `{self::$data_table}` // using static property
      WHERE `$property` = '$value'";
    // send query, get $ids array
    $obj_array = array();
    foreach($ids as $id) {
      // create array of current class objects using special static keyword
      // meaning of static here is different than in property/method declarations
      $obj_array[$id] = new static($id);
    }
    return $obj_array;
  }
}

Dirò che i principi che hanno sono ok ma l'affermazione (non usare la statica) potrebbe essere sbagliata. Quanto costa la copertura del tuo codice? se il numero è alto e ti senti a tuo agio con il test unitario della tua app, allora stai bene. In caso contrario, suggerirei di rivedere il codice. Potresti scoprire che le classi statiche sono la ragione o no, dipenderà da molte cose.

Le classi con metodi statici abusano dei principi di OOP. Non è già un OOP, è una programmazione orientata alla classe COP.

Raramente hanno una "personalità" chiara (qui uso la mia metafora umana preferita ) o identità. Quindi non sanno chi sono. Questo punto da solo è sufficiente per sbarazzarsi di questo concetto in OOP, ma ce ne sono altri.

Il prossimo è una conseguenza del primo punto. Dal momento che tali classi non sanno chi sono, tendono ad essere grandi o grandi.

Il terzo rende il codice assolutamente non gestibile. L'uso di metodi statici introduce dipendenze nascoste . Appaiono dappertutto e non sai mai cosa sta succedendo nella tua classe. Non puoi esserne sicuro guardando la firma del costruttore.

Lentamente, ma inevitabilmente, il tuo codice sta diventando sempre meno coeso, poiché le dipendenze nascoste sono scarsamente controllate. Sembrano invisibili. Ed è così facile aggiungerne un altro! Non è necessario modificare la firma di alcun metodo. Tutto quello che devi fare è chiamare un metodo statico. E che brutto codice segue ...

Ok, probabilmente hai già indovinato. L'accoppiamento stretto è spesso associato a bassa coesione. Se ci sono molti client che usano una classe, allora l'accoppiamento sta diventando più stretto. E c'è una grande seduzione nell'usare una classe o un metodo già scritti che richiedono solo una piccola correzione. Un solo parametro parametro parametro.

Cosa usare invece di metodi statici? Bene, il mio suggerimento è OOP. Perché non provarlo?