Skip to content

Instantly share code, notes, and snippets.

@PalumboN
Created October 15, 2019 22:01
Show Gist options
  • Save PalumboN/9135e0f822c6e78a8799967d570b94c5 to your computer and use it in GitHub Desktop.
Save PalumboN/9135e0f822c6e78a8799967d570b94c5 to your computer and use it in GitHub Desktop.
Ejercicio de herencia vs composición - continuación de https://gist.github.com/PalumboN/036c4bb65567ba7287d365b54bb60702

Tercera parte

Ya vimos que los Aprendices de Brujo tienen un tutor, y nos enteramos que el tutor los habilita para cambiar de rango a Archimago. Cada vez que el aprendiz usa un hechizo, el tutor debe determinar si ya es suficientemente groso para dejar de ser aprendiz. Cada tutor podría tener su propio criterio para evaluar al aprendiz, no nos interesa ahondar en eso ahora mismo.

Luego, como Archimago, es posible subir de nivel cada vez que se usa un hechizo que requiera más del 50% de su energía máxima. A partir del nivel 20, se vuelve Hechicero Supremo, que es el último rango alcanzable.

Para pensar

Podría tener sentido querer que no todos los hechiceros entiendan el mensaje para saber si un hechicero puede dejar de ser aprendiz (y cualquier otro mensaje que sea propio de ser un tutor), y por ende no se considerarían tutores.

Qué alternativas hay para que un tutor sea un hechicero que puede tener cualquiera de esos rangos también, sin que sea instancia de la misma clase que instanciamos para crear un hechiciero que no se considera tutor y pudiendo agregar lógica propia de los tutores?

Si no existe una necesidad de que los hechiceros que no son tutores pasen a ser tutores, o que un tutor deje de serlo, en principio se podría plantear una herencia para indicar que un Tutor es un Hechicero, conviviendo con la solución que usa composición para los rangos sin ningún problema. Agregar lógica propia de los tutores en la subclase Tutor resolvería el problema.

Otra alternativa podría ser definir una clase Tutor que conozca un hechicero, y que delegue en el hechicero cuando haga falta. De esa forma el tutor puede entender más mensajes de los que entienden los hechiceros y para aquellos métodos para los cuales que queremos que se comporte como un hechicero común, se puede delegar en la instancia de Hechicero. Esta solución es más compleja porque nuevamente hay más de un objeto para representar una misma idea, y la mecánica se puede llegar a complicar más de lo que queremos y tener problemas luego a los cuales no nos anticipamos (por ejemplo, redefinir cosas en el tutor sería trivial usando herencia, pero con esta solución una vez que delegamos algo al hechicero difícilmente podamos usar lógica propia del tutor, porque desde el código del hechicero self es la instancia de Hechicero, no de Tutor).

Como conclusión, ya vimos que existe más de un mecanismo para modelar problemas similares. Es importante no sólo saber manejar ambos sino también entender las consecuencias que trae aparejada cada solución. La herencia simple es muy útil, pero está lejos de ser una bala de plata, por eso a medida que van surgiendo problemas más complejos toma más importancia ser capaces de solucionarlos de más de una forma para luego decidir cuál es más adecuada, para evitar problemas a futuro sin volvernos locos.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment