Buenas, adjunto mi solución a estos ejercicios. Se me complicó bastante la diferenciación entre si un socio era VIP o no, me parece que se podría implementar mejor con una clase Socio VIP y otra Socio a secas, pero como el enunciado nombraba dos clases nada mas no estaba seguro de que hacer.
Edit: no me está dejando adjuntar ningún tipo de archivo, me dice "No se puedo escribir el archivo en el disco".
Saludos!
Ahi pude!
Hola Alejandro:
Está bien la solución que planteás aunque no tan orientada a objetos. Te hago algunas observaciones:
- La clase Socio quedó casi sin responsabilidades. Solamente se encarga de almacenar su nombre, la cantidad pagada y un String que hace referencia a su tipo. La clase Club, por el contrario, hace prácticamente todo, cuando lo ideal es que le delegara algunas tareas al socio.
- No es conveniente utilizar variables del tipo String para almacenar datos que no sean más que nombres y que realmente necesiten ser Strings. En tu modelo hiciste que la variable tipoDeSocio sea un String pero ese no es un atributo necesario en el modelo. Solamente lo utilizás para poder desde afuera determinar qué tarifa aplicar. ¿No sería mejor que directamente se guarde la tarifa correspondiente? De esta forma sería el socio quien sepa su tarifa y no el club.
- No es necesario que escribas una prueba para verificar que el nombre del socio se haya establecido correctamente. Si bien no está mal, por lo general preferimos no incluir las pruebas de simples getters y setters dado que no verifican ningún comportamiento y generan más ruido que otra cosa.
- Las otras dos pruebas de Socio están bien, pero te quedaron tan pocas justamente porque el Socio quedó con muy pocas responsabilidades.
Saludos,
Tomás
Buenas Tomás, gracias por las correciones. Me queda entonces la duda de si habría que partir la clase socio en dos, una para los VIPs y otra para los comunes. Con lo de cambiar el string a el costo de la cuota en si, seguiría teniendo el mismo problema de tener que hacer un check true or false para ver que tipo de cuota tener que aplicar.
Entendido lo de los test por otro lado.
Gracias!
Fijate que el Club tiene estos dos métodos:
- agregarSocio: unSocio
- agregarSocioVIP: unSocio
En ambos casos se recibe un socio común y corriente y lo que podés hacer ahí, además de guardarte al socio, es asignarle la tarifa que corresponde según cada caso. De esta forma cada socio sabría su tarifa y no tendría idea de que hay socios que pagan más o menos qué él/ella y no necesitás ningún if en ningún lado.
Si en futuras iteraciones se complejizaran las responsabilidades de las tarifas se podría analizar la posibilidad de modelar alguna clase Tarifa o similar, pero por ahora no vale la pena.
Saludos,
Tomás
Perfecto, gracias!