La razón por la que usualmente creamos una subclase es porque el comportamiento de la subclase es diferente que la superclase, veamos un ejemplo donde no se aplica correctamente este principio:
En este ejemplo, ¿el comportamiento de la clase Guitarra es diferente de la clase Instrumento? ¿Es diferente la funcionalidad de un Mandolin ó de un Banjo?, la respuesta para ambas preguntas en No, todos los instrumentos tienen el mismo comportamiento.
Un argumento por el que podemos defender este diseño es que todos los instrumentos tienen diferentes propiedades o que la clase Instrumento representa una abstracción y no un objeto real, estos podrían ser buenas razones, pero provocaría un trabajo extra y haría nuestro software inflexible y difícil de cambiar.
Por lo cual aplicando el principio "Clases tratan acerca de comportamiento y funcionalidad" el resultado de nuestro diseño sería el siguiente:
La clase Instrumento ya no es Abstracta y añadimos un nueva propiedad para saber que tipo de instrumento es.
Si tuvieramos que escribir una aplicación que representara como esos instrumentos van a ser tocados, entonces si tendríamos que definir subclases para manejar ese comportamiento diferente como tocarInstrumento(), iniciarSonido(), etc.
No hay comentarios:
Publicar un comentario