Come è cattiva dichiarare la variabile statica pubblica e usarla in altre classi?

Le variabili globali non sono mai necessarie a meno che tu non stia interagendo con il codice esistente che impone vincoli inadatti.

Un'alternativa è rendere esplicita la dipendenza:

1. Crea una classe che descriva lo scopo di questi dati condivisi. Senza conoscere il dominio del problema, lo chiamerò Counter .

class Counter {
  private int value = 0;

  public void incrementBy(int x) {
    if (x < 0)
      throw IllegalArgumentException("must increment by non-negative value");
    value += x;
  }

  public int get() { return value; }
}

Si noti che avvolgere la variabile attraverso le funzioni di accesso ci consente di imporre controlli e vincoli. Questa mancanza di controlli è uno dei problemi principali nell'esporre le variabili direttamente.

2. Utilizza un meccanismo di iniezione dipendente per fornire un'istanza Counter a tutte le classi che ne hanno bisogno. Ad esempio, possiamo utilizzare l'iniezione del costruttore:

public class ClassName2 {
  private Counter counter;

  public ClassName2(Counter counter) {
    this.counter = counter;
  }

  public void meth(){
    counter.incrementBy(4);
  }
}

Il contatore viene creato in un codice di inizializzazione (come la tua funzione main ()) e poi fornito quando le classi dipendenti sono istanziate:

Counter counter = new Counter();
ClassName  instance  = new ClassName(counter);
ClassName2 instance2 = new ClassName2(counter);

Tutte le variabili globali hanno un'istanza simile, ma sono eseguite in modo implicito durante il caricamento della classe. Gestendo da soli l'inizializzazione otteniamo molta flessibilità:

• possiamo fornire una classe Counter diversa durante il test.
• siamo in grado di utilizzare più istanze di Counter se non si suppone che parti diverse del codice condividano un contatore, ad esempio quando la funzionalità ClassName originale viene riutilizzata in un contesto diverso.

Se non puoi rendere esplicite queste dipendenze, almeno incapsula la variabile usando metodi statici in modo simile.

La cosa brutta non è che C2 dipenda da C1. Riusare le lezioni è una buona cosa. Se ha senso definire il compito di una classe parzialmente in termini di compito di un'altra, allora con tutti i mezzi farlo. Il punto sull'esposizione dello stato pubblico da una classe è che compromette il vantaggio del riutilizzo e dell'incapsulamento.

Esempio: se hai una classe Fridge , vuoi che si prenda cura dei tuoi deperibili, e idealmente il frigorifero sarebbe abbastanza intelligente da impostare una temperatura ragionevole da solo, piuttosto che averlo microgestito. Un buon set-up sarebbe quello di consegnare al tuo frigorifero un oggetto IceCream o Cetriolo e lasciare che il frigorifero decida automaticamente quanto freddo debba essere conservato il contenuto. Mettere un cetriolo e impostare manualmente la temperatura su 4 è più lavoro e introduce una possibilità di errore in cui il tipo di cibo e il valore della temperatura non corrispondono. Se nel tuo sistema deve esserci conoscenza su come refrigerare diversi alimenti, allora dovrebbe risiedere nella classe Fridge e non separatamente in ogni utente di quella classe.