Para responder a su pregunta específica: No, desde el punto de vista del aprendizaje de un idioma, la recursividad no es una característica. Si tu profesor realmente te quitó las notas por usar una "función" que aún no había enseñado, estaba mal.
Al leer entre líneas, una posibilidad es que al usar la recursividad, evitó usar una característica que se suponía que era un resultado de aprendizaje para su curso. Por ejemplo, tal vez no usó iteración en absoluto, o tal vez solo usó forbucles en lugar de usar ambos fory while. Es común que una tarea tenga como objetivo probar su capacidad para hacer ciertas cosas, y si evita hacerlas, su profesor simplemente no puede otorgarle las calificaciones reservadas para esa función. Sin embargo, si esa fue realmente la causa de sus calificaciones perdidas, el profesor debe tomar esto como una experiencia de aprendizaje propia, si demostrar ciertos resultados de aprendizaje es uno de los criterios para una tarea, eso debe explicarse claramente a los estudiantes. .
Habiendo dicho eso, estoy de acuerdo con la mayoría de los otros comentarios y respuestas de que la iteración es una mejor opción que la recursividad aquí. Hay un par de razones, y aunque otras personas las han mencionado hasta cierto punto, no estoy seguro de que hayan explicado completamente la idea que hay detrás de ellas.
Desbordamientos de pila
El más obvio es que corre el riesgo de obtener un error de desbordamiento de pila. Siendo realistas, es muy poco probable que el método que escribió conduzca a uno, ya que un usuario tendría que dar una entrada incorrecta muchas veces para activar un desbordamiento de pila.
Sin embargo, una cosa a tener en cuenta es que no solo el método en sí, sino otros métodos más altos o más bajos en la cadena de llamadas estarán en la pila. Debido a esto, engullir casualmente el espacio disponible en la pila es algo bastante descortés para cualquier método. Nadie quiere tener que preocuparse constantemente por el espacio libre en la pila cada vez que escribe código debido al riesgo de que otro código haya usado una gran cantidad innecesariamente.
Esto es parte de un principio más general en el diseño de software llamado abstracción. Básicamente, cuando llame DoThing(), lo único que debería preocuparle es que la cosa esté lista. No debería tener que preocuparse por los detalles de implementación de cómo se hace. Pero el uso codicioso de la pila rompe este principio, porque cada bit de código tiene que preocuparse por cuánta pila puede asumir con seguridad que le ha dejado el código en otra parte de la cadena de llamadas.
Legibilidad
La otra razón es la legibilidad. El ideal al que debería aspirar el código es ser un documento legible por humanos, donde cada línea describe simplemente lo que está haciendo. Adopte estos dos enfoques:
private int getInput() {
int input;
do {
input = promptForInput();
} while (!inputIsValid(input))
return input;
}
versus
private int getInput() {
int input = promptForInput();
if(inputIsValid(input)) {
return input;
}
return getInput();
}
Sí, ambos funcionan, y sí, ambos son bastante fáciles de entender. Pero, ¿cómo se podrían describir los dos enfoques en inglés? Creo que sería algo como:
Solicitaré la entrada hasta que la entrada sea válida y luego la devolveré
versus
Solicitaré una entrada, luego, si la entrada es válida, la devolveré; de lo contrario, obtengo la entrada y devuelvo el resultado de eso.
Tal vez pueda pensar en una redacción un poco menos torpe para el último, pero creo que siempre encontrará que el primero será una descripción más precisa, conceptualmente, de lo que realmente está tratando de hacer. Esto no quiere decir que la recursividad sea siempre menos legible. Para situaciones en las que brilla, como el cruce de árboles, puede hacer el mismo tipo de análisis lado a lado entre la recursividad y otro enfoque y es casi seguro que encontrará que la recursividad proporciona un código que es más claramente autodescriptivo, línea por línea.
De forma aislada, ambos son puntos pequeños. Es muy poco probable que esto conduzca realmente a un desbordamiento de la pila, y la mejora en la legibilidad es menor. Pero cualquier programa va a ser una colección de muchas de estas pequeñas decisiones, por lo que incluso si de forma aislada no importan mucho, es importante aprender los principios detrás de hacerlas bien.