Cuando pensamos en POO siempre caemos en que cuanto más usemos herencia más orientado objeto esta. Y claramente no es así. Es decir si tenemos este pensamiento estamos comenzando con el pie izquierdo; estamos pensando en "programación orientada a clases". Claro estamos generalizando de ante mano.
Lo ideal (que no quiere decir que en el día a día lo haga) es imaginar el problema con solo objetos. Una representación del problema; como una simulación. Sin interesarnos en clases, datos, etc.
Luego que ya entendimos el problema; pensamos como se comportan los objetos. Hay objetos que se comportan similar y los podemos generalizar entonces tenemos nuestra clase!!!
Hora tenemos un conjunto de clases y vemos que algunas tienen el mismo comportamiento, entonces podemos generalizar en una clase padre.
Claro esta que esto en teoría es muy fácil, el problema es la práctica. Veamos un problema aparentemente fácil, una academia donde tenemos alumnos y profesores. Fácil no? Una clase persona de la cual heredan la clase Alumno y Profesor. Muy fácil !!!
Momento ... y si un alumno también es profesor. Mmm... NO era tan fácil.
Con el modelo presentado hacemos agua, donde estuvo el error el primer paso, NO ENTENDIMOS EL PROBLEMA!!!
Lo escrito no es un descubrimiento filosófico ni un pensamiento que va a cambiar tu vida profesional. Simplemente una reflexión y recordatorio, antes de pensar en herencia y clases; pensemos: ¿entiendo el problema?
muy buen post. Estoy de acuerdo contigo. Antes de comenzar a pensar en el diseño debemos tener bien en claro cuales son los requerimientos, como vos decis, entender el problema.
ResponderBorrarEl ejemplo de la academia muy claro.
bueno, normalmente se explica el diagrama de clases como una interpretación de los requerimientos. Ahora, tendria cuidado con el ejemplo que das, el polimorfismo es parte fundamental de la orientación a objetos y nos permite que una persona sea bien un almumno o un profesor.
ResponderBorrarSaludos
Se denomina polimorfismo a la capacidad que tienen los objetos a responder un mismo mensaje.
ResponderBorrarNo entiendo como esto puede tener que ver con el ejemplo. Es decir el alumno responde los mensajes de alumno y el profesor de profesor. No tengo mensajes de persona, solo estoy centralizando datos.
bueno, si te quedas con la definición de wikipedia.es no estás del todo bien, ese "polimorfismo" se denomina "sobrecarga de operadores" y está en discución dicho error Revisa nuevamente en google y ojalá en inglés.
ResponderBorrarAhora volviendo al ejemplo, tengo profesores que son alumnos de Dotorado. Una misma persona sí puede ser Profesor o Alumno dependiendo del escenario en que se desenvuelvan.
Persona sería una clase abstracta y Profesor y Alumno, clases que extienden a Persona.
Me parece correcto lo que decis, pero el ejemplo es solo para demostrar que tal vez no es necesario pensar en herencia.
ResponderBorrarEs decir la herencia no debería pensarse en base a datos, si no a comportamiento.
Por ejemplo Emanuel es profesor y alumno entonces que hago?
Cuando es alumno:
Alumno emanuel = new Alumno();
Cuando es profesor:
Profesor emanuel = new Profesor();
Estas teniendo dos objetos para representar 1 que vive en la realidad.
Tal vez es mejor hacer una clase persona que tenga lista de roles.
Saludos.
Hola
ResponderBorrarSiguiendo tu comentario del 9 de agosto tengo una duda, esa clase general "Persona" tiene la lista de roles, entonces tiene asociadas clases que contienen metodos que son utiles para que la clase "Persona" pueda especializarse? por ejemplo digamos que existe una clase "X" asociada a Persona con los metodos especiales de un profesor, digamos "enseñar" es correcta mi afirmacion? gracias de antemano
Sip, es así. El mecanismo para obtener las características de Profesor sería un poco más complicado.
ResponderBorrar