Per rispondere alla tua domanda specifica: No, dal punto di vista dell'apprendimento di una lingua, la ricorsione non è una caratteristica. Se il tuo professore ti ha davvero tolto i voti per aver usato una "caratteristica" che non aveva ancora insegnato, era sbagliato.
Leggendo tra le righe, una possibilità è che usando la ricorsione, hai evitato di usare una caratteristica che avrebbe dovuto essere un risultato di apprendimento per il suo corso. Ad esempio, forse non hai usato affatto l'iterazione, o forse hai usato solo i forloop invece di usare sia fore while. È normale che un incarico miri a testare la tua capacità di fare determinate cose e, se eviti di farle, il tuo professore semplicemente non può assegnarti i voti riservati per quella funzione. Tuttavia, se questa fosse davvero la causa dei tuoi voti persi, il professore dovrebbe prenderla come una sua esperienza di apprendimento - se la dimostrazione di determinati risultati di apprendimento è uno dei criteri per un compito, ciò dovrebbe essere spiegato chiaramente agli studenti .
Detto questo, sono d'accordo con la maggior parte degli altri commenti e risposte sul fatto che l'iterazione è una scelta migliore rispetto alla ricorsione qui. Ci sono un paio di ragioni, e mentre altre persone le hanno toccate in una certa misura, non sono sicuro che abbiano spiegato completamente il pensiero dietro di loro.
Stack Overflow
Quello più ovvio è che rischi di ricevere un errore di overflow dello stack. Realisticamente, è molto improbabile che il metodo che hai scritto porti a uno, poiché un utente dovrebbe fornire un input errato molte volte per attivare effettivamente un overflow dello stack.
Tuttavia, una cosa da tenere a mente è che non solo il metodo stesso, ma altri metodi superiori o inferiori nella catena di chiamate saranno nello stack. Per questo motivo, inghiottire casualmente lo spazio disponibile nello stack è una cosa piuttosto scortese da fare per qualsiasi metodo. Nessuno vuole doversi preoccupare costantemente dello spazio libero nello stack ogni volta che scrive codice a causa del rischio che altro codice possa averne usato inutilmente molto.
Questo fa parte di un principio più generale nella progettazione del software chiamato astrazione. In sostanza, quando chiami DoThing(), tutto ciò di cui dovresti preoccuparti è che la cosa sia fatta. Non dovresti preoccuparti dei dettagli di implementazione di come è fatto. Ma un uso avido dello stack infrange questo principio, perché ogni bit di codice deve preoccuparsi di quanto stack può tranquillamente presumere di avergli lasciato dal codice altrove nella catena di chiamate.
leggibilità
L'altro motivo è la leggibilità. L'ideale a cui il codice dovrebbe aspirare è di essere un documento leggibile dall'uomo, in cui ogni riga descrive semplicemente cosa sta facendo. Adotta questi due approcci:
private int getInput() {
int input;
do {
input = promptForInput();
} while (!inputIsValid(input))
return input;
}
contro
private int getInput() {
int input = promptForInput();
if(inputIsValid(input)) {
return input;
}
return getInput();
}
Sì, funzionano entrambi e sì, sono entrambi abbastanza facili da capire. Ma come potrebbero essere descritti i due approcci in inglese? Penso che sarebbe qualcosa del tipo:
Chiederò l'input finché l'input non sarà valido, quindi lo restituirò
contro
Chiederò l'input, quindi se l'input è valido lo restituirò, altrimenti ottengo l'input e restituisco il risultato di quello invece
Forse puoi pensare a una formulazione leggermente meno goffa per quest'ultimo, ma penso che troverai sempre che il primo sarà una descrizione più accurata, concettualmente, di ciò che stai effettivamente cercando di fare. Questo non vuol dire che la ricorsione sia sempre meno leggibile. Per le situazioni in cui brilla, come l'attraversamento degli alberi, potresti fare lo stesso tipo di analisi fianco a fianco tra la ricorsione e un altro approccio e quasi sicuramente troverai che la ricorsione fornisce un codice che è più chiaramente auto-descrittivo, riga per riga.
In isolamento, entrambi sono piccoli punti. È molto improbabile che ciò porti davvero a un overflow dello stack e il guadagno in leggibilità è minore. Ma qualsiasi programma sarà una raccolta di molte di queste piccole decisioni, quindi anche se isolatamente non contano molto, è importante imparare i principi che stanno dietro a farle bene.