Imposta il metodo di ritorno su booleano per determinare se il prossimo metodo deve essere eseguito

Question

Imposta il metodo di ritorno su booleano per determinare se il prossimo metodo deve essere eseguito

#1 da (1 voti)
#2 da (0 voti)

1

Sono curioso di sapere se questo design è considerato una buona o cattiva pratica.

Ho un dispatcher e una classe di servizio.

Dispatcher ho il seguente:

public void doBeforeUpdate(Map<Id,sObject> oldMap, Map<Id,sObject> newMap, List<sObject> triggerOld, List<sObject> triggerNew) {

    Boolean myBool = service.myCheck(triggerOld, triggerNew);

    if(!myBool){
        Boolean newBool = false;

        for(sObject oldInfo: triggerOld){
            for(sObject newInfo: triggerNew){
                if(newInfo.price < oldInfo.price){
                    newBool = true;
                }
            }
        }

        if(newBool){
            service.priceChanged(triggerNew);
        }
    }

}

Nel mio servizio ho il seguente:

public static Boolean myCheck(List<sObject> triggerOld, List<sObject> triggerNew){

    Boolean myBool = false;

    for(sObject oldInfo: triggerOld){
        for(sObject newInfo: triggerNew){
            if(newInfo.Id == oldInfo.Id && newInfo.Name != oldInfo.Name){
                myBool = true;
                break;
            }
        }
        if(myBool) break;
    }

    return myBool;

}

La mia domanda è, è buona o cattiva pratica che myBool nel dispatcher sia impostato su un metodo di ritorno dal servizio per determinare se il codice e il metodo nell'istruzione if vengono eseguiti nel dispatcher. Sto lavorando in Apex. Il mio pensiero è, farlo in questo modo mi risparmia tempo di elaborazione se la prima condizione non riesce. Non dovrei preoccuparmi di questo? È bene o male impostare un booleano basato su un metodo di ritorno? È appena finito di uccidere e ci sto pensando? Qualsiasi suggerimento sarebbe davvero apprezzato. Grazie.

object-oriented design design-patterns object-oriented-design

posta bemon 15.09.2017 - 19:30

fonte

2 risposte

Leggi altre domande sui tag object-oriented design design-patterns object-oriented-design

Dividi le richieste tra diverse applicazioni server Windows Installer: aggiornamenti software e hot-fix

score 1 · Answer 1

Se utilizzi "ritorno anticipato" , puoi evitare interamente le dichiarazioni Boolean e break .

public static Boolean myCheck(List<sObject> triggerOld, List<sObject> triggerNew){

    for(sObject oldInfo: triggerOld){
        for(sObject newInfo: triggerNew){
            if(newInfo.Id == oldInfo.Id && newInfo.Name != oldInfo.Name){
                return true;
            }
        }
    }

    return false;
}

Vedi anche
Programmazione computer / Stile di codifica / Minimizza annidamento / Ritorno anticipato

score 0 · Answer 2

Oltre a ciò che Robert Harvey ha detto nella sua risposta, stai anche facendo più lavoro del necessario nel tuo ciclo Dispatcher. Sarebbe più semplice fare qualcosa del genere:

public void doBeforeUpdate(Map<Id,sObject> oldMap, Map<Id,sObject> newMap, List<sObject> triggerOld, List<sObject> triggerNew) {

    Boolean myBool = service.myCheck(triggerOld, triggerNew);

    if(!myBool){
        for(sObject oldInfo: triggerOld){
            for(sObject newInfo: triggerNew){
                if(newInfo.price < oldInfo.price){
                    service.priceChanged(triggerNew);
                    return;
                }
            }
        }
    }
}

Questo non è solo un ritorno anticipato. È anche (potenzialmente) facendo meno iterazioni del ciclo. Come lo avevi già fatto, continuavi ad andare in loop dopo che sapevi già che avevi bisogno di fare il cambio di prezzo.

Ci possono essere altri modi per architettarlo. Piuttosto che dover cercare l'elenco per vedere se ci sono dei cambiamenti, sarebbe possibile che le modifiche attivino qualcosa che dice al tuo committente che avrà sicuramente bisogno di fare qualcosa? Ad esempio, quando le informazioni sul prezzo vengono cambiate, invia una notifica indicante che è necessario un aggiornamento. A seconda del resto della tua architettura e della natura dei tuoi dati, potrebbe essere o non essere il modo migliore per gestirli, ma volevo solo menzionare che ci sono altri modi per fare lo stesso lavoro, dal momento che sembra essere il tuo domanda.