Come semplificare la logica "IF" del business complicato?

Question

Quali sono i modi migliori per gestire una complessa logica aziendale che, a prima vista, richiede numerose istruzioni nidificate if?

Esempio:

Buono sconto. potrebbe essere:

sconto 1a) Valore
1b) Percentuale sconto

2a) sconto normale
2b) riduzione progressiva

3a) Richiede accesso coupon
3b) non richiedono accesso coupon

4a) Applicato solo al cliente che ha già acquistato prima
4b) Applicato a qualsiasi cliente

5a) Applicato al cliente solo da paesi (X, Y, ...)

che richiede il codice ancora più complicato allora questo:

if (discount.isPercentage) { 
    if (discount.isNormal) { 
     if (discount.requiresAccessCoupon) { 
     } else { 
     } 
    } else if (discount.isProgressive) { 
     if (discount.requiresAccessCoupon) { 
     } else { 
     } 
    } 
} else if (discount.isValue) { 
    if (discount.isNormal) { 
     if (discount.requiresAccessCoupon) { 
     } else { 
     } 
    } else if (discount.isProgressive) { 
     if (discount.requiresAccessCoupon) { 
     } else { 
     } 
    } 
} else if (discount.isXXX) { 
    if (discount.isNormal) { 
    } else if (discount.isProgressive) { 
    } 
} 

Anche se si sostituisce FI per passare/caso è ancora troppo complicato Quali sono i modi per renderlo leggibile, mantenibile, più testabile e facile da capire?

Answer 1

Scriverei una macchina di stato generica che si alimenta in elenchi di cose da confrontare.

Answer 2

Specification pattern potrebbe essere quello che stai cercando.

Sommario:

Nella programmazione di computer, il modello di specifica è un particolare design pattern, per cui la logica di business può essere ricombinato per concatenazione logica di business insieme usando la logica booleana.

Answer 3

Scopo orientato modo di farlo è di avere più classi sconti attuazione un'interfaccia comune:

dicsount.apply(order) 

Mettere la logica per determinare se l'ordine qualifica per lo sconto all'interno delle classi di sconto.

Answer 4

Il mio primo pensiero è che questo non è testabile, il che mi porta a una soluzione, al fine di farlo testabile.

if (discount.isPercentage) { 
    callFunctionOne(...); 
} else if (discount.isValue) { 
    callFunctionThree(...); 
} else if (discount.isXXX) { 
    callFunctionTwo(...); 
} 

Quindi è possibile che ogni istruzione nidificata sia una chiamata separata. In questo modo puoi testarli individualmente e quando provi il gruppo numeroso sai che ognuno lavora.

Answer 5

Creare metodi che verificano un caso particolare.

bool IsValueNormalAndRequiresCoopon (Sconto) {...}

bool IsValueNormalAndRequiresCoupon (Sconto) {...}

ecc

Una volta che si inizia a fare che diventa più facile da vedere dove si può astrarre dalla logica comune tra le scelte. Puoi quindi andare da lì.

Per decisioni complesse, spesso finisco con una classe che gestisce gli stati possibili.

Answer 6

Utilizzare guard clauses potrebbe aiutare alcuni.

Answer 7

Buona domanda. "Complessità condizionale" è un odore di codice. Polymorphism è tuo amico.

logica condizionale è innocente nella sua infanzia, quando è semplice da capire e contenuta entro poche linee di codice. Sfortunatamente, invecchia raramente bene. Implementa diverse nuove funzionalità e improvvisamente la logica condizionale diventa complicata ed espansiva. [Joshua Kerevsky: Rifattorizzazione Patterns]

Una delle cose più semplici si può fare per evitare nidificato se i blocchi è quello di imparare ad usare Guard Clauses.

double getPayAmount() { 
if (_isDead) return deadAmount(); 
if (_isSeparated) return separatedAmount(); 
if (_isRetired) return retiredAmount(); 
return normalPayAmount(); 
}; 

L'altra cosa che ho trovato semplifica le cose abbastanza bene, e che rende il vostro codice di auto-documentazione, è Consolidating conditionals.

double disabilityAmount() { 
    if (isNotEligableForDisability()) return 0; 
    // compute the disability amount 

Altri preziosi refactoring tecniche associate a espressioni condizionali sono Decompose Conditional, Replace Conditional with Visitor, e Reverse Conditional.

Answer 8

FWIW, ho usato con successo Hamcrest per questo genere di cose. Credo che potresti dire che implementa il modello delle specifiche, di cui @Arnis ha parlato.

Answer 9

Si dovrebbe davvero vedere

Clean Code Talks - Inheritance, Polymorphism, & Testing
di Miško Hevery

Google Tech Talks 20 novembre 2008

RIASSUNTO

è il codice completo di istruzioni if? Cambiare le dichiarazioni? Hai la stessa dichiarazione di commutazione in vari punti? Quando apporti dei cambiamenti, ti ritrovi a fare lo stesso cambiamento allo stesso se/cambi in più punti? Hai mai dimenticato uno?

Questo intervento discuterà gli approcci all'utilizzo di tecniche orientate agli oggetti per rimuovere molti di questi condizionali. Il risultato è un codice più pulito, più stretto e meglio progettato che è più facile da testare, comprendere e mantenere.