condividi il codice tra i metodi di controllo e di processo

Question

condividi il codice tra i metodi di controllo e di processo

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

2

Il mio lavoro è quello di refactoring una vecchia libreria per l'elaborazione dei dati vettoriali GIS. La classe principale racchiude una raccolta di profili di costruzione e offre diversi metodi per il controllo della coerenza dei dati. Quelle funzioni di controllo hanno un parametro opzionale che consente di eseguire alcuni processi. Ad esempio:

std::vector<Point> checkIntersections(int process_mode = 0);

Questo metodo verifica se alcuni profili di costruzione si intersecano e restituiscono i punti di intersezione. Ma se si passa un argomento non nullo, il metodo modificherà i contorni per rimuovere l'intersezione.

Penso che sia piuttosto brutto (sul sito di chiamata, un lettore che non ha familiarità con il codice base presumerà che un metodo chiamato checkSomething esegua solo un controllo e non modifichi i dati) e voglio cambiarlo. Voglio anche evitare la duplicazione del codice poiché i metodi di controllo e di processo sono per lo più simili.

Quindi stavo pensando a qualcosa di simile:

// a private worker
std::vector<Point> workerIntersections(int process_mode = 0)
{
    // it's the equivalent of the current checkIntersections, it may perform
    // a process depending on process_mode
}


// public interfaces for check and process
std::vector<Point> checkIntersections()  /* const */
{
    workerIntersections(0);
}


std::vector<Point> processIntersections(int process_mode /*I have different process modes*/)
{
    workerIntersections(process_mode);
}

Ma questo mi costringe a rompere la correttezza const come workerIntersections è un metodo non const.

Come posso separare il controllo e l'elaborazione, evitando la duplicazione del codice e mantenendo la correttezza?

design c++

posta undu 11.12.2012 - 10:14

fonte

2 risposte

1

Basta cambiare il nome di checkIntersections per checkOrProcessIntersections.

Nota più seria: -
Hai detto che questa è una vecchia biblioteca. Quindi, se si modifica il comportamento, il vecchio cliente non ne risentirà? Il mio consiglio sarà di mantenere le checkIntersections. Aggiungi altri due metodi strictCheckIntesection o onlyCheckIntersection e processIntersections. E poi dal tuo checkIntersections chiama questi due metodi, a seconda del parametro di input.
Inoltre non ti sei preoccupato per la costanza. Se alcune funzioni stanno cambiando lo stato, sta cambiando lo stato. In ogni caso non sarà costante.

risposta data 11.12.2012 - 11:01

fonte

Leggi altre domande sui tag design c++

In JSF, dove oggetti come PhaseListeners si adattano al pattern MVC? Quale algoritmo di apprendimento automatico [s?] sarebbe applicabile qui?

score 0 · Accepted Answer

Penso che tu sia sulla strada giusta con la revisione dei nomi delle funzioni come hai suggerito. Ciò ti consentirà di chiarire l'intento di ciò che sta accadendo e di ridurre al minimo la duplicazione del codice.

Suggerirei di chiamare processIntersections() qualcosa di diverso però. updateIntersections() o checkAndUpdateIntersections() sarebbero due suggerimenti. L'intento è di avvicinare il nome della funzione a ciò che sta effettivamente accadendo.

Non sono sicuro di capire la preoccupazione per la "cost-correttezza". Hai detto che workerIntersections sarebbe un metodo privato, quindi è effettivamente nascosto al di fuori di quella classe. Se la preoccupazione è di fornire una garanzia di sola lettura ai chiamanti di checkIntersections() , allora direi che mettere const su checkIntersections() è un bel-to-have, ma non è necessariamente richiesto. Se dovessi scegliere tra quella garanzia e quella di minimizzare il codice duplicato, allora andrò con meno codice. Dato che si tratta di un'API interna utilizzata dalla tua azienda, non mi preoccuperei della garanzia.

Ma questo è stato detto ... Se la garanzia è veramente importante, allora considera di rompere la funzionalità di workerIntersections() a parte. Quello che hai fatto finora è mettere una facciata di fronte alla funzione originale per chiarire l'intento. Per fornire la garanzia const , dovrai interrompere la funzione originale in una funzione const checkOnly() e una makeUpdates(int mode) .

Che tu continui o meno con la facciata che hai suggerito dipende solo da te. Dal momento che hai già altri chiamanti che forniscono una modalità, potresti voler mantenere la facciata o potrebbe essere altrettanto semplice rifattorizzarli allo stesso tempo in cui interrompi la funzione originale.