Questo codice può essere reso più conciso? [chiuso]

Question

Questo codice può essere reso più conciso? [chiuso]

#1 da (4 voti)
#2 da (-1 voti)

0

Mi sono imbattuto recentemente in qualche codice dove in molti, molti posti, le valutazioni di espressioni venivano assegnate a diversi array un indice alla volta. Un esempio di psuedo-code:

array[0] = item1[0] + item2[0];
array[1] = item1[1] + item2[1];
array[2] = item1[2] + item2[2];

o

array[0] /= variable;
array[1] /= variable;
array[2] /= variable;

Il mio istinto sarebbe quello di creare prima una funzione per iterare attraverso un array e assegnare una valutazione usando un singolo ciclo for. Poi, in secondo luogo, basta chiamare quella funzione con argomenti per l'array, un numero che definisce quanti indici attraversare e gli elementi da valutare.

Ovviamente, un ostacolo a quel metodo è il fatto che il le espressioni valutate sono arbitrarie - possono essere aggiunte, sottrazioni, divisioni, moltiplicazioni.
E per un altro, gli operandi di espressione possono essere variabili o matrici e di corso in lingue tipizzate staticamente, i tipi potrebbero essere variati.
Inoltre, il numero di operandi può essere variato.

È possibile rendere questo codice più conciso tenendo conto di tutti i possibili casi e quale sarebbe la soluzione in termini tecnici?

design clean-code

posta Orkwad 30.06.2014 - 06:48

fonte

2 risposte

-1

Oltre a ciò che ha scritto 'Frank', hai costruito qualcosa come strategia, un abstract Operator class che il suo costruttore prende due argomenti e ha un metodo di myCalc che restituisce il valore. Quindi avere per ciascuna operazione aritmetica o matematica e classe derivata. Usando i generici puoi persino ottenere tipi diversi come parametri.

Quindi sul tuo codice lo scrivi così: array[i] = calc(value1,value2,new plus())

dove calc è semplicemente return Op.calc(value1,value2)

risposta data 30.06.2014 - 09:31

fonte

Leggi altre domande sui tag design clean-code

Qual è l'operazione di "moltiplicazione del 1620"? Overhead enorme di aggiunta lunga rispetto alla chiamata nativa?

score 4 · Accepted Answer

Sì, certo che è:)

Hai ragione nel ritenere che la creazione di un ciclo semplifica già le cose, quindi permettimi di rispondere alle tue preoccupazioni più dettagliate al riguardo:

Espressioni arbitrarie: mentre le espressioni stesse possono essere arbitrarie, possono comunque essere rappresentabili come una funzione. Quando stai pensando in una mentalità di programmazione più funzionale, ti renderai conto che tutto quello che stai facendo è mappare una funzione sugli elementi dell'array.
Differenza di tipo: questa è la ragione, perché abbiamo il polimorfismo. Quando si esegue il mapping astratto su una matrice di tipo T con una funzione che restituisce T s, non ci si deve preoccupare della differenza di tipo.
Numero di operandi: viene catturato dal primo punto sopra. Poiché ci interessa solo mappare una funzione su questo array, non ci interessa il numero degli argomenti di quella funzione.

Quindi, in generale, il mio suggerimento su come semplificare questo sarebbe quello di dare un'occhiata più da vicino ai principi di programmazione funzionale, in particolare, le funzioni di livello superiore (cioè le funzioni, che prendono un'altra funzione come parametro).

Si noti che FP può essere il modo più semplice e diretto per semplificarlo, ma anche se non si lavora in un linguaggio FP (che è molto probabile comunque), le sue idee sono trasferibili alla maggior parte delle lingue. Potresti tuttavia investire di più in strutture / classi di supporto, il che potrebbe rendere la semplificazione piuttosto complessa nel complesso. Ma tieni presente che i concetti di alto livello come la mappatura di una funzione su alcuni elementi sono estremamente riutilizzabili, quindi potrebbe valerne la pena di fare un piccolo investimento in anticipo.