Internacionalización como parámetro al objeto para identificar el idioma.

[fjavier]

Problema:

Actualmente se requiere llamar diferentes clases por cada idioma del cual se requiere obtener el texto, teniendolo de esta manera, tendriamos que crear una clase por cada nuevo idioma que quisiéramos agregar. Number2Text converter = new SpanishNumber2Text(1);

Recomendación:

Seria mucho mas sencillo para los que implementen la funcionalidad y mucho mas mantenible hacer el llamado a una sola clase, la cual se le pase como primer parametro el idioma, si no se le pasa el parámetro del idioma entonces por defecto que el idioma sea español.

Number2Text converter = new Number2Text("es", 1); Number2Text converter = new Number2Text("en", 1);

Como recomendación seria utilizar internacionalización para crear este nuevo feature

Criterios de aceptación

• [ ] Pruebas Unitarias.
• [ ] Evidencias

[armalagon]

Me parece muy buena la idea de no tener que instanciar las implementaciones de los idiomas directamente. Number2Text es una clase abstracta, por lo tanto no la podemos instanciar, lo que sí podemos hacer es agregar métodos de fábrica estáticos en esta clase que representen cada idioma. Como el constructor de la clase tiene diferentes firmas (5 versiones en total), debemos alinear la firma de estos nuevos métodos estáticos con los constructores.

El cambio se vería así:

Number2Text converter = Number2Text.spanish(1_250);
Number2Text converter = Number2Text.spanish(1_250, (eventType, conversionType, event, output) -> {});

String letter = converter.toText();

String anotherLetter = Number2Text.spanish(1_250).toText();

Hace poco @berroteran sugirió otra idea que me parece puede ser cubierta en esta historia: se debe invocar el método toText() para obtener el valor en letras y para simplificar aún más el código podrímos devolver directamente el texto y no una instancia del convertidor usando métodos estáticos de fábrica. Sólo hay un aspecto a considerar: el método toText tiene 4 firmas (una de ellas no tiene parámetros, lo que dejaría 3 en total) y sus parámetros deben ser incluídos en cada método estático para preservar la funcionalidad intacta. Esta idea hay que sopesarla porque se agregarían 2 parámetros y se tendrían que crear las combinaciones de uso con estos 2 parámetros lo que aumentaría la cantidad de firmas de los métodos estáticos.

A continuación las variantes usando el constructor Number2Text(long):

String letter = Number2Text.spanish(1_250); // sin parametros
String letter2 = Number2Text.spanish(1_250, (numberToLetter, decimalPart) -> numberToLetter, true); // 2 parametros
String letter3 = Number2Text.spanish(1_250, (numberToLetter, decimalPart) -> numberToLetter); // 1 parametro
String letter4 = Number2Text.spanish(1_250, true); // 1 parametro

Cuando soportemos más idiomas (digamos unos 4), retomaría tu idea con un ligero ajuste, usar el object Locale para parametrizar el idioma y no un String.

[berroteran]

Number2Text(long) se ve mas fácil de implementar, aunque no estoy seguro si ya se instació previamente.

so? caso cerrado?