Hola

Acabo de estar leyendo el tutorial sobre JUnit y he llegado hasta TDD.

He estado pensando en eso de evitar código repetido y dejar que TDD nos lleve al diseño, pero estoy un poco liado y ya no sé qué es buen diseño y qué es mal diseño:

Me ha venido a la cabeza la clase Math (o Strictmath) del paquete java.lang. Estas clases tienen métodos repetidos para datos tipo double, tipo float y tipo int. Por ejemplo Math.max(a, b). ¿Según TDD una clase como esa no está bien diseñada?. Lo digo porque para evitar código repetido sería conveniente escribir cada método una sola vez y que reciban una interfaz como "ItfzNumero" o algo así, o una clase "ClssNumero" que haga de wrapper de cualquier tipo de número.

Por otro lado para comparar dos objetos a y b de esa clase habrá que comprobar qué tipo de número envuelven y comprarlos y generar el resultado en lugares distintos del código usando "if(a.getClass().equals("double"))" o bien usando "switch"... Con lo que al final estaríamos en las mismas, sólo habríamos transladado el código repetido a otra clase. O hacer un casting y devolver siempre double?? (No, eso no me parece práctico ni elegante)...

Bueno, he dicho muchas cosas y no váis a saber a qué responderme. Creo que puedo formular mi pregunta así: ¿Según TDD habría que cambiar clases del estilo de java.lang.Math para que cada método esté escrito sólo una vez?

Hola:

Lo de buen diseño y mal diseño es más bien una cosa subjetiva y depende mucho de la finalidad que tengan esas clases.

Por ejemplo, la clase Math está hecha para ser usada por la gente, por lo que un buen diseño "externo" es el que facilita la vida a los programadores para su uso. En ese caso, es mejor tener muchos métodos repetidos de forma que tú puedas usar directamente los double, int, long de java directamente y obtener el resultado sin tener que hacer cast. Si haces lo de IfzNumero, estás complicando su uso a los programadores, por lo que desde el punto de vista de uso externo, no sería una buena opción.

El otro punto de vista es el de mantenimiento del código. Si piensas en los desarrolladores de sun que han hecho java y que mantienen el código interno de la clase Math, posiblemente tener muchos métodos repetidos no sea una buena opción de diseño, ya que cualquier cosa que tengan que tocar, tienen que tocarla en varios métodos. Pero habría que ver el fuente interno de la clase Math, porque quizás todos esos métodos repetidos no tengan el código repetido dentro o si hay código repetido, igual lo han extraido a un único método privado de la clase (o público).

Por ello, a la hora de elegir "buen" diseño, debes tener en cuenta si estás haciendo una librería para que usen otros desarrolladores o una aplicación completa para que usen los usuarios.

En cualquier caso, lo de código repetido se refiere a lo siguiente. Si alguien te pide un cambio puntual en la lógica de tu programa.... ¿en cuántos sitios tienes que tocar?. Si es en más de uno, tienes código repetido.

En cuanto a lo de comparar la posible IfzNumero o ClassNumero, bastaría con hacer que esa IfzNumero o ClassNumero tuviera, por ejemplo, un método getDouble() (fíjate en la clase Number de java, que de alguna forma es la ClassNumero que mencionas).

Y finalmente, aprovecho también para comentarte que en las clases de java, hay cosas que no están bien hechas desde el punto de vista de diseño para usar. La gente de Sun, aunque sean buenos profesionales, son humanos como todos y algo como java es un proyecto de mucha embergadura, con sus bugs, sus prisas y sus "cosas". Un ejemplo típico de estos fallos que se menciona mucho es que exista una clase Observable, pero no una interface Observable. Si quieres implementar el patrón observador en java usando esta clase, tu objeto observable no puede heredar de otra clase tuya y de Observable a la vez, ya que java no admite herencia múltiple.

Se bueno.