ENTREGA 5 - Gonzalo-F/DDS-2014 GitHub Wiki

1.- Se cambió el new de jugador, para que en el mismo se pudiese directamente elegir la manera en la cual se va a inscribir al partido. Así se evitó que cada jugador al crearse se lo haga en modo estándar y luego cambiarlo a solidario.

2.- En el test se creaba un partido que luego no se utilizaba para nada. Esto ensuciaba el código y prestaba confusión al no saber que significado tenia que este creado y no se use, por lo tanto se eliminó toda la creación e inscripción de jugadores del mismo.

**3.- **El código repetido que había en las clases de ordenamiento, se subió a la clase padre logrando una mayor abstracción y la no repetición del código.

4.- Se preguntaba por el "tipo" de la clase de inscripción que tenía un jugador para saber si dejaba el lugar para inscribirse a otro o no, para esto se le delego la responsabilidad a cada clase de decir si dejaba o no hacerlo. Esto también contribuyó a que no sea un String el modo de inscripción. Si bien ahora en nuestro diseño estas clases lo único que hacen es devolver un valor, y por ende comparten código (bad smell, se podría hacer solo una clase y setear el valor a devolver) se decidió dejarlo así ya que creemos que en refactors futuros la responsabilidad de inscripción al partido pueda tenerla el modo de inscripción.

5.- La clase Equipo era una data class, ya que lo unico que hacia era tener la lista de los dos equipos formados sin exhibir ningún comportamiento. En el refactor hecho, las listas de equipos son atributos propios del partido.

6.- El estado del partido estaba modelado con Strings, en el nuevo diseño se implementaron clases que modelan esos estados, evitando los ifs que se hacían para preguntar por cada uno para ver el curso a seguir. En este caso se decidió dejar en clases separadas al estado abierto y equipos generados, aunque ambos tiren excepción, pensado en que en un futuro podría agregarle algún comportamiento extra al alguna.

**7.- **Los test que tenian definido (expected=typeof(BusinessException)), si bien esto es correcto, a simple vista nos parecía mejor visualmente que se trate de agarrar la excepción correspondiente. Además, se reemplazó la BusinessException por dos excepciones que cada una se corresponde con el estado del partido, ya que si bien la excepción tenía un string de descripción de la misma, nos parece más significativo que cada excepción represente el curso de acción que hizo que se corte la ejecución.

8.- En el before de los test se hizo un refactor a la manera de inscribir a los jugadores en el partido ya que se repetía código. Se extrajeron las líneas de inscribir en un método el cual recibe al partido y la lista de jugadores a inscribir por parámetro, e inscribe a los jugadores de la lista en el partido pasado.

9.- Se reificaron los criterios de distribución de equipos. Pasan de ser un int poco expresivo (5=par/impar, 16=criterio X), dentro de un IF, a ser objetos con comportamiento propio. Nos permite agregar/modificar criterios más fácilmente , con solo crear/modificar el comportamiento de una clase. 10.- En el método inscribir ya se esta verificando que que haya algún jugador inscripto al partido que ceda el lugar, por lo que es innecesario que luego el método jugadorQueCedeLugar vuelva a hacerlo. Además el nombre del método no da a entender que este haga alguna validación previa, simplemente debe devolver el jugador que lo ceda.

11.- En la clase Partido, los métodos hayAlgunJugadorQueCedaLugar y jugadorQueCedeLugar estaban rompiendo el encapsulamiento de jugador al hacer jugador.criterioInscripcion.dejaLugarAotro, por lo que se extrajo esa linea de código en un método que lo tiene la clase Jugador.

**12.- **Se extrajeron métodos varios. En Partido: _cantidadInscriptos, _reemplazar(jugador): saca de la lista a un jugador que ceda el lugar y agrega al jugador pasado parámetro. En las líneas que había this.getInscriptos.add(jugador) se modificó por this.agregarJugador(jugador). En el test: _Se reemplazaron las líneas que hacían partido.inscriptos.contains(jugador), por un método auxiliar que lo haga. _ Extrajimos los métodos que generan los listados de jugadores ordenados, para facilitar la lectura/entendimiento de la funcionalidad del test

DIAGRAMA DE CLASE https://www.lucidchart.com/documents/edit/53df2e30-3440-4710-9052-8c7b8028153b/0