Come evitare lunghe catene di chiamate?

Question

Come evitare lunghe catene di chiamate?

#1 da (6 voti)
#2 da (1 voti)

3

Ho una gerarchia di oggetti, per lo più connessi per composizione. Cioè (non mostra i metodi di classe per la leggibilità):

class A {}
class B {A a;}
class C {B b;}
etc...
class Z {Y y;}

class Z fornisce l'API per l'esecuzione di comandi da un altro programma: un pannello di controllo. Penso che questo si chiami Chain of Responsibility , ma potrebbe essere un errore.

Ora quando un'azione deve essere eseguita su A, Z chiama un metodo di Y , perché Z conosce solo circa Y . Così via, finché non raggiungiamo A , che ha i membri e i metodi corretti per gestire la richiesta.

Questo ha il problema fondamentale che il debug diventa noioso - uno deve step in molte volte, e ogni volta fai attenzione a non perdere l'effettivo metodo di lavoro - altrimenti la sessione di debug deve essere riavviata.

Come faccio a rendere il debug più semplice? Un cambiamento nell'architettura di un metodo di utilizzo di gcc più adatto a questa situazione?

debugging c++ gcc method-chaining

posta Vorac 31.10.2014 - 10:11

fonte

2 risposte

Leggi altre domande sui tag debugging c++ gcc method-chaining

Converti codice procedurale in object oriented È fuorviante etichettare il codice come un particolare modello di progettazione se solo si adatta alla definizione in modo approssimativo?

score 6 · Answer 1

Quando dividi i grandi metodi in piccoli, e separa le preoccupazioni in molte classi, e scrivi più funzioni con livelli di astrazione chiaramente separati, finirai con lunghe catene di chiamate, è vero. Ma quando scegli le tue astrazioni, il tuo codice diventa molto più leggibile e comprensibile rispetto alla tipica funzione spagetthi a 200 linee di codice.

E il codice leggibile evita un sacco di bug in prima persona, quindi per la mia esperienza questo supera i maggiori sforzi di debug causati dalle catene di chiamate da una moltitudine. Quindi il mio consiglio è: vivi con esso. Non usare questa argomentazione "lunga catena di chiamate rende più difficile il debugging" come una scusa per non rielaborare il tuo codice in funzioni più piccole, tale ragionamento porta sempre a un errore.

Come suggerimento per il debug in caso di mancata perdita della causa di un errore: alcuni debugger ( come gdb ) ti permettono per "annullare" i tuoi ultimi passaggi nel mezzo di una sessione di debug.

score 1 · Answer 2

Usa registrazione. (Non so quali siano le opzioni di registrazione in c ++, ma sarei sorpreso se non ci fosse qualcosa di simile a ciò che è disponibile in Java).

Accedi al metodo di inserimento e uscita e a cosa sta andando / esce (e lo fai in modo automatico configurabile, o solo in posti interessanti). In questo modo sai dove è andato e se riesci a formulare postcondizioni e precondizioni, puoi controllarli quando passano attraverso i log per trovare dove sta accadendo qualcosa di strano e poi inserire il breakpoint nel posto giusto.

Quando lo stesso metodo viene chiamato ripetutamente e solo dopo che il log viene eseguito scomposto su border case, puoi usare il breakpoint condizionale, perché sai (dai log) quali dati causano problemi.

Ciò richiederà più esecuzioni per esaminare il problema, ma l'esecuzione del log sarà senza step manuale, molto più veloce, e in esecuzione di debug si avvierà più vicino al problema actuall (o almeno più vicino alla sua manifestazione.