Calcolo e restituzione di un oggetto secondario in cui l'oggetto secondario è archiviato nell'oggetto

3

Ho un oggetto complesso che ha bisogno di calcolare regolarmente un sottooggetto che rappresenta vari aspetti dello stato del genitore come un fascio. Ad esempio, immagina che l'oggetto rappresenti informazioni su un velivolo e che l'oggetto secondario sia un riepilogo di vari parametri chiave dell'aeromobile in un momento particolare come la sua direzione, velocità, ecc. L'oggetto deve memorizzare l'ultima versione calcolata del sub-oject.

Attualmente il modo in cui lo faccio è che ho un metodo di vuoto nell'oggetto che computa il calcolo e quindi imposta una variabile a livello di modulo per essere uguale al sub-oggetto di nuova elaborazione. L'utente esterno di questo sottooggetto recupera il sotto-oggetto corrente tramite un getter. Quindi, per i metodi client l'operazione è simile a questa:

main_object.computeState();
State new_state = main_object.getState();

Per gestire possibili errori, tuttavia, nel calcolo, che al momento non viene eseguito, sto pensando di passare a un metodo di calcolo che restituisce lo stato:

State new_state = main_object.computeState( error_msg );
if( new_state == null ){
   print( error_msg );
   goto failure continuation
}
.... [everything ok, continue normally ]

Esiste una strategia migliore per la costruzione di questo modello?

    
posta Tyler Durden 08.09.2015 - 16:56
fonte

2 risposte

3

Quello che stai suggerendo è IMHO piuttosto semplice, vorrei solo prendere in considerazione l'utilizzo di eccezioni per la gestione degli errori se il tuo linguaggio di programmazione lo consente. Ad esempio:

 try
 {
     State new_state = main_object.computeState();
     .... [everything ok, continue normally ]
 }
 catch(MyException ex)
 {
    print( ex.error_msg );
    ... do further error processing
 }
    
risposta data 08.09.2015 - 18:28
fonte
3

So, for the client methods the operation looks like this:

main_object.computeState();
State new_state = main_object.getState();

Questo è un cattivo schema. Stai esponendo tutto il codice client a un dettaglio di implementazione di main_object. Questo complica il codice client, complica le future ottimizzazioni di main_object e porta a bug quando qualche programmatore chiama getState () senza chiamare computeState ().

Dovresti fornire un singolo metodo di main_object che i client possono chiamare per ottenere lo stato corrente. Questo metodo può chiamare computeState se necessario. A volte in futuro potresti scoprire che non è necessario chiamare computeState per ogni chiamata a getState.

Il metodo getState () dovrebbe occuparsi di chiamare computeState ogni volta che è necessario.

    
risposta data 08.09.2015 - 19:25
fonte

Leggi altre domande sui tag