Quale stile è meglio (variabile di istanza vs. valore di ritorno) in Java

Mi trovo spesso in difficoltà a decidere quale di questi due modi utilizzare quando devo utilizzare dati comuni attraverso alcuni metodi nelle mie classi. Quale sarebbe una scelta migliore?

In questa opzione, posso creare una variabile di istanza per evitare la necessità di dichiarare variabili aggiuntive e anche per definire i parametri del metodo, ma potrebbe non essere chiaro dove siano istanziate / modificate tali variabili:

public class MyClass {
    private int var1;

    MyClass(){
        doSomething();
        doSomethingElse();
        doMoreStuff();
    }

    private void doSomething(){
        var1 = 2;
    }

    private void doSomethingElse(){
        int var2 = var1 + 1;
    }

    private void doMoreStuff(){
        int var3 = var1 - 1;
    }
}

O semplicemente istanziare le variabili locali e passarle come argomenti?

public class MyClass {  
    MyClass(){
        int var1 = doSomething();
        doSomethingElse(var1);
        doMoreStuff(var1);
    }

    private int doSomething(){
        int var = 2;
        return var;
    }

    private void doSomethingElse(int var){
        int var2 = var + 1;
    }

    private void doMoreStuff(int var){
        int var3 = var - 1;
    }
}

Se la risposta è che sono entrambi corretti, quale viene visto / usato più spesso? Inoltre, se è possibile fornire ulteriori vantaggi / svantaggi per ciascuna opzione sarebbe molto utile.

Sono sorpreso che questo non sia ancora stato menzionato ...

Dipende se var1fa effettivamente parte dello stato dell'oggetto .

Supponi che entrambi questi approcci siano corretti e che sia solo una questione di stile. Tui hai torto.

Questo è interamente su come modellare correttamente.

Allo stesso modo, privateesistono metodi di istanza per mutare lo stato dell'oggetto . Se non è quello che sta facendo il tuo metodo, dovrebbe essere private static.

Non so quale sia la più diffusa, ma farei sempre quest'ultima. Comunica più chiaramente il flusso e la durata dei dati e non gonfia ogni istanza della classe con un campo la cui unica durata rilevante è durante l'inizializzazione. Direi che il primo è solo confuso e rende la revisione del codice significativamente più difficile, perché devo considerare la possibilità che qualsiasi metodo possa modificare var1.

Dovresti ridurre l' ambito delle tue variabili il più possibile (e ragionevole). Non solo nei metodi, ma in generale.

Per la tua domanda ciò significa che dipende se la variabile fa parte dello stato dell'oggetto. Se sì, è OK usarlo in quell'ambito, cioè l'intero oggetto. In questo caso vai con la prima opzione. In caso contrario, scegli la seconda opzione in quanto riduce la visibilità delle variabili e quindi la complessità complessiva.

Quale stile è meglio (variabile di istanza vs. valore di ritorno) in Java

C'è un altro stile: usa un contesto / stato.

public static class MyClass {
    // Hold my state from one call to the next.
    public static final class State {
        int var1;
    }

    MyClass() {
        State state = new State();
        doSomething(state);
        doSomethingElse(state);
        doMoreStuff(state);
    }

    private void doSomething(State state) {
        state.var1 = 2;
    }

    private void doSomethingElse(State state) {
        int var2 = state.var1 + 1;
    }

    private void doMoreStuff(State state) {
        int var3 = state.var1 - 1;
    }
}

Ci sono una serie di vantaggi in questo approccio. Gli oggetti di stato possono cambiare indipendentemente dall'oggetto, ad esempio, dando molto spazio per il futuro.

Questo è un modello che funziona bene anche in un sistema distribuito / server in cui alcuni dettagli devono essere conservati attraverso le chiamate. È possibile memorizzare i dettagli dell'utente, le connessioni al database, ecc state. Nell'oggetto.

Si tratta di effetti collaterali.

Chiedere se var1fa parte dello stato manca il punto di questa domanda. Certo se var1deve persistere, deve essere un'istanza. Entrambi gli approcci possono essere fatti per funzionare se la persistenza è necessaria o meno.

L'approccio agli effetti collaterali

Alcune variabili di istanza vengono utilizzate solo per comunicare tra metodi privati ​​da una chiamata all'altra. Questo tipo di variabile di istanza può essere refactored dall'esistenza ma non deve esserlo. A volte le cose sono più chiare con loro. Ma questo non è senza rischi.

Stai lasciando uscire una variabile dal suo ambito perché è usata in due diversi ambiti privati. Non perché è necessario nell'ambito che lo stai posizionando. Questo può essere fonte di confusione. I "globi sono cattivi!" livello di confusione. Questo può funzionare ma non si adatta bene. Funziona solo nel piccolo. Nessun grande oggetto. Nessuna catena di eredità lunga. Non causare un yo-yo effetto .

L'approccio funzionale

Ora, anche se var1deve persistere, nulla dice che devi usare se per ogni valore transitorio potrebbe assumere prima di raggiungere lo stato che desideri conservare tra le chiamate pubbliche. Ciò significa che puoi ancora impostare avar1 un'istanza utilizzando nient'altro che metodi più funzionali.

Quindi, parte dello stato o no, puoi comunque usare entrambi gli approcci.

In questi esempi 'var1' è incapsulato in modo che nulla oltre al debugger sappia che esiste. Immagino che tu l'abbia fatto deliberatamente perché non vuoi influenzarci. Fortunatamente non mi interessa quale.

Il rischio di effetti collaterali

Detto questo, so da dove viene la tua domanda. Ho lavorato con miserabile yo yo 'ing eredità che muta una variabile di istanza a più livelli in diversi metodi e andato scoiattoli cercando di seguirlo. Questo è il rischio.

Questo è il dolore che mi spinge ad un approccio più funzionale. Un metodo può documentare le sue dipendenze e l'output nella sua firma. Questo è un approccio potente e chiaro. Ti consente inoltre di modificare ciò che passi al metodo privato rendendolo più riutilizzabile all'interno della classe.

Il lato positivo degli effetti collaterali

È anche limitante. Le funzioni pure non hanno effetti collaterali. Questa può essere una buona cosa ma non è orientata agli oggetti. Una grande parte dell'orientamento agli oggetti è la capacità di fare riferimento a un contesto esterno al metodo. Farlo senza far trapelare i globi da queste parti e scomparire è la forza di OOP. Ottengo la flessibilità di un globale ma è ben contenuto nella classe. Posso chiamare un metodo e mutare ogni variabile di istanza contemporaneamente se mi piace. Se lo faccio, sono obbligato almeno a dare al metodo un nome che chiarisca cosa sta facendo in modo che le persone non siano sorprese quando ciò accade. Anche i commenti possono aiutare. A volte questi commenti sono formalizzati come "condizioni post".

L'aspetto negativo di metodi privati ​​funzionali

L'approccio funzionale rende alcuni dipendenze. A meno che tu non sia in un linguaggio funzionale puro, non può escludere dipendenze nascoste. Non sai, guardando solo la firma di un metodo, che non ti nasconde un effetto collaterale nel resto del suo codice. Semplicemente no.

Post condizionali

Se tu e tutti gli altri membri del team documentate in modo affidabile gli effetti collaterali (condizioni pre / post) nei commenti, il vantaggio derivante dall'approccio funzionale è molto inferiore. Sì, lo so, continua a sognare.

Conclusione

Personalmente tendo verso metodi privati ​​funzionali in entrambi i casi, se possibile, ma onestamente è principalmente perché quei commenti sugli effetti collaterali pre / post condizionali non causano errori del compilatore quando sono obsoleti o quando i metodi vengono chiamati fuori servizio. A meno che non abbia davvero bisogno della flessibilità degli effetti collaterali, preferirei solo sapere che le cose funzionano.

La prima variante sembra non intuitiva e potenzialmente pericolosa per me (immagina per qualsiasi motivo che qualcuno renda pubblico il tuo metodo privato).

Preferirei molto istanziare le tue variabili sulla costruzione di una classe, o passarle come argomenti. Quest'ultimo ti dà la possibilità di usare modi di dire funzionali e di non fare affidamento sullo stato dell'oggetto contenitore.

Ci sono già risposte che parlano dello stato dell'oggetto e di quando si preferisce il secondo metodo. Voglio solo aggiungere un caso d'uso comune per il primo modello.

Il primo modello è perfettamente valido quando tutto ciò che fa la tua classe è che incapsula un algoritmo . Un caso d'uso per questo è che se si scrivesse l'algoritmo in un singolo metodo sarebbe troppo grande. Quindi lo scomponi in metodi più piccoli, lo rendi una classe e rendi i metodi secondari privati.

Ora passare tutto lo stato dell'algoritmo tramite parametri potrebbe diventare noioso, quindi usi i campi privati. È anche in accordo con la regola del primo paragrafo perché è fondamentalmente uno stato dell'istanza. Devi solo tenere a mente e documentare correttamente che l'algoritmo non è rientrante se usi campi privati ​​per questo . Questo non dovrebbe essere un problema per la maggior parte del tempo, ma può forse morderti.

Proviamo un esempio che fa qualcosa. Perdonami dato che questo è javascript non java. Il punto dovrebbe essere lo stesso.

Visita https://blockly-games.appspot.com/pond-duck?lang=en , fai clic sulla scheda javascript e incolla questo:

hunt = lock(-90,1), 
heading = -135;

while(true) {
  hunt()  
  heading += 2
  swim(heading,30)
}

function lock(direction, width) {
  var dir = direction
  var wid = width
  var dis = 10000

  //hunt
  return function() {
    //randomize() //Calling this here makes the state of dir meaningless
    scanLock()
    adjustWid()
    if (isSpotted()) {
      if (inRange()) {
        if (wid <= 4) {
          cannon(dir, dis)
        }
      }
    } else {
      if (!left()) {
        right()
      }
    }
  }

  function scanLock() {
    dis = scan(dir, wid);
  }

  function adjustWid() {
    if (inRange()) {
      if (wid > 1)
        wid /= 2;
    } else {
      if (wid < 16) {
        wid *= 2; 
      }
    }
  }

  function isSpotted() {
    return dis < 1000;
  }

  function left() {
    dir += wid;
    scanLock();
    return isSpotted();
  }

  function right() {
    dir -= wid*2;
    scanLock();
    return isSpotted()
  }

  function inRange() {
    return dis < 70;
  }

  function randomize() {
    dir = Math.random() * 360
  }
}

Dovresti notare che dir, wide disnon stai passando molto in giro. Dovresti anche notare che il codice nella funzione che lock()restituisce assomiglia molto allo pseudo codice. Bene, è un vero codice. Eppure è molto facile da leggere. Potremmo aggiungere passaggi e assegnazioni, ma ciò aggiungerebbe disordine che non vedresti mai nello pseudo codice.

Se vuoi sostenere che non fare l'assegnazione e il passaggio va bene perché quei tre var sono uno stato persistente, considera una riprogettazione che assegna dirun valore casuale ad ogni ciclo. Non persistente ora, vero?

Certo, ora potremmo cadere dir di portata ora, ma non senza essere costretti a ingombrare il nostro codice pseudo simile con il passaggio e l'impostazione.

Quindi no, lo stato non è il motivo per cui decidi di utilizzare o meno gli effetti collaterali piuttosto che passare e tornare. Né gli effetti collaterali da soli significano che il tuo codice è illeggibile. Non si ottengono i vantaggi del puro codice funzionale . Ma ben fatti, con buoni nomi, possono effettivamente essere belli da leggere.

Ciò non significa che non possano trasformarsi in spaghetti come un incubo. Ma allora cosa non può?

Buona caccia alle anatre.