cambiando il valore dell'oggetto String in java

0

Devo impostare il valore di un oggetto stringa "risultato" in base ai risultati di diversi metodi e diverse condizioni if / else. Alla fine, ci sarebbe uno (ultimo valore impostato) nella stringa che ho bisogno di usare. Il primo modo in cui l'ho fatto è:

public void MyClass(){

        public void validateApples() {
            String result = "failure";

            if (condition 1) {
                //do something
            }

            if (condition 2) {
                //do something
            }

            if(condition 3) {
                //do something
            }

            if (condition 4) {

               if (condition a)
                    result = "success";                    
                } else{
                    //One of the first three conditions resulted in failure so don't change string value
                }
            }

            if (condition 5) {
                //Do validation only for xml files
                result = validateMachintoshApples ();
            }
       }

      private String validateMachintoshApples() {
         String result;            

            result = oneStepValidation();             

       return result;
     }


     private String oneStepValidation(){
         String result;           

         if (some condition) {    
            // some code
            result = "success";   
        }else{
            // some code
            result = "failure";
        }
        return result;
    }


}

Sento che sto ricreando un nuovo oggetto String molte volte in diversi metodi della stessa classe. Non penso sia efficiente in termini di memoria, tempo di creazione dell'oggetto e standard di codifica.

Ho poi spostato la creazione di un oggetto stringa "risultato" per l'intera classe e l'ho assegnato a "fallimento" o "successo" perché penso che sarebbe stato più pulito codice (vedi codice sotto)

1) Ma dal momento che le punture sono immutabili in JAVA, otterrò qualcosa in questo modo?

2) Sto ancora creando una nuova stringa ogni volta con result="failure" o result="success" o è solo una variazione di valore? Dubito che sia un cambiamento di valore in quanto le stringhe sono immutabili.

3) La seconda via è meno leggibile poiché le funzioni impostano il valore per il risultato ma non restituiscono nulla?

4) Quale dovrebbe essere la migliore pratica in questo caso?

Il mio secondo modo di codifica è il seguente:

public void MyClass(){

    private String result;

    public String getResult() {
        return result;
    }

    public void setResult(String result) {
        this.result = result;
    }

    public void validateApples() {


        if (condition 1) {
            //do something
            result = "failure";
        }

        if (condition 2) {
            //do something
            result = "failure";
        }

        if(condition 3) {
            //do something
            result = "failure";
        }

        if (condition 4) {

           if (condition a)
                result = "success";                    
            } else{
                //One of the first three conditions resulted in failure 
            }
        }

        if (condition 5) {
            //Do validation only for xml files
            validateMachintoshApples ();
        }
   }

  private void validateMachintoshApples() {

        result = oneStepValidation();             

 }


 private void oneStepValidation(){

     if (some condition) {    
        // some code
        result = "success";   
    }else{
        // some code
        result = "failure";
    }

}

}
    
posta gogogaga 01.03.2018 - 16:16
fonte

2 risposte

2

Diamo un'occhiata a questo per un minuto o due ...

Quindi stai eseguendo del codice e ti aspetti una stringa di ritorno per dirti come è andata. Nel fare questo hai notato (e giustamente) che questo evoca un sentimento un po 'spiacevole, questo non mi sembra giusto. Il problema tuttavia non è una delle prestazioni, o piuttosto la performance è solo un ramoscello che nasconde la foresta terrificante alle spalle.

Il primo cambiamento che puoi fare qui è quello di sostituire i valori di stringa con il solo codice fisso ovunque con le costanti. Questo coprirà i casi in cui si commettono errori di battitura che assegnano il valore che impedisce ai casi di essere rilevati dal chiamante.

Ma sembra ancora sbagliato no?

Bene, puoi aiutare un po 'di più aiutando il compilatore. Metti tutti i valori possibili in un enum e assegnalo. Qui non lavoriamo più direttamente con le stringhe ma con oggetti reali con un tipo e un insieme di valori strettamente controllati. Non è possibile alcun errore di battitura e ti consente di assicurarti di coprire tutti i possibili valori di ritorno (nei casi in cui ottieni più di "successo" o "fallimento")

Se hai solo bisogno di due casi, un booleano farebbe semplicemente dandy, true = ok, false = fail ...

Eppure puoi ancora fare di meglio qui ...

inserisci Eccezioni

Tutto questo codice è fondamentalmente per verificare che qualcosa è ciò che dovrebbe essere giusto? Quindi in pratica hai un caso di successo e uno o più tipi di errore.

quindi invece di restituire un valore che deve essere controllato, non restituire nulla. SE tutto va bene, il codice viene eseguito normalmente. Se la convalida fallisce, l'errore genererà un'eccezione che tu avrai creato (ValidationException o qualcosa di simile) che verrà catturato da un codice chiamante, potrebbe essere il chiamante diretto, potrebbe essere anche più in alto nello stack. Fondamentalmente verrà catturato a un livello in cui si può fare qualcosa al riguardo.

Hai bisogno di più tipi di convalida? (proprio come l'enum precedente) crea sottoclassi di questa ValidationException per ogni tipo di problema che necessita di essere rilevato. In questo modo riordinerai il tuo codice che si occupa del caso normale dandoti i mezzi per aggregare il codice di gestione dove è importante.

Per farla breve, il linguaggio offre potenti strumenti per gestire errori come questo, abbracciarli. Troverai il tuo codice molto più facile da leggere e gestire.

    
risposta data 01.03.2018 - 17:00
fonte
0

Non c'è niente di sbagliato nel senso che result verrà aggiornato ogni volta. Le prestazioni non sono una preoccupazione qui. Questo è un modo molto comune di scrivere metodi / funzioni:

private int MethodName()
{
   int result = 0;
   if (condition1)
   {
      result = 1;
   } 
   else if (condition2)
   {
      result = 2;
   } 
   else if (condition3)
   {
      result = 3;
   }
}

Un'altra alternativa comune:

private int MethodName()
{
   if (condition1)
   {
      return 1;
   } 
   else if (condition2)
   {
      return 2;
   } 
   else if (condition3)
   {
      return 3;
   }

   return 0;
}

Nota che nel tuo primo esempio, result è una variabile locale, con scope alla funzione validateApples() e mai restituita. Quindi, non è usato al di fuori di quella funzione. Fai tutte le convalide, ma non fare nulla con la risposta. Nel secondo esempio, result è un membro privato della classe, quindi il suo valore viene aggiornato come parte della funzione validateApples() e può quindi essere utilizzato dalla funzione getResult() della classe.

Tuttavia, considera il caso in cui condition 1 , condition 2 o condition 3 sono vere. In questo caso, result = "failure" . Ora, se condition 4a è true, result = "success" , oscurando l'errore precedente. Tutte le tue dichiarazioni if sono proprio quelle: if dichiarazioni, non if else . Quindi ognuno verrà eseguito, potenzialmente sovrascrivendo result dell'istruzione precedente. Se è quello che vuoi, va bene, ma di solito non è così: non vuoi che un errore sia coperto e che abbia successo.

Come menzionato nei commenti, stai usando "success" e "failure" molte volte nel codice, che li renderebbero candidati ideali per costanti o persino enum. Si potrebbe anche voler considerare le eccezioni invece per i fallimenti. Entrambe queste cose renderebbero il codice molto più leggibile e molto più robusto.

Per una revisione più approfondita del codice, potresti voler postare su codereview.stackexchange.com; Saranno in grado di criticare il tuo codice reale molto meglio di quello che possiamo qui.

    
risposta data 01.03.2018 - 16:59
fonte

Leggi altre domande sui tag