Especificar más información a la abstracción - Modelo de Clases

[wigglyUtrera]

Hola, tengo una duda que no sé muy bien resolver.

Pongamos de ejemplo (ilustrativo):
https://dl.dropboxusercontent.com/u/3065296/UMLAbs.PNG

Las clases Java Coche y Conductor son abstractas. y la relación tiene navegabilidad hacia Conductor, es decir, Coche tendrá un atributo de tipo Conductor con la información de este.

Por lo que la clase CocheAutomatico tendrá un Conductor.

¿Cómo puedo modelar que un CocheAutomatico solo puede tener ConductorAutomatico? Quiero mantener la abstración para que el modelo sea más flexible y minimice el cambio en un futuro, además que el modelo es más limpio, pero faltaría indicar ese matiz.

¿Cuál sería la mejor opción? ¿OCL?

Muchas gracias.

Un saludo

[kraneok]

Pues igual que las clases tiene relaciones, puedes indicar la multiplicidad debajo de la clase conductor.

[wigglyUtrera]

No entiendo a lo que te refieres.

Podría tener una relación entre las clases hijas, pero entonces tendría la información duplicada. La del padre que heredo y esa nueva relación.

Gracias por la respuesta.

Un saludo.

[Xerelo]

Yo tampoco entiendo bien a qué te refieres, pero por si acaso aclarar que las variables no se deben sobreescibir.

Si lo intentas no te dará error, pero tendrá comportamientos extraños*.

Si tú tienes en la clase Coche un objeto Conductor, en CocheAutomatico no debes sobreescribir la variable conductor Conductor por ConductorAutomático, a conductor Conductor puedes pasarle un ConductorAutomático, pero no que sólo acepte ConductorAutomático.



*En realidad no se sobreescribe, se "esconde" una.

[wigglyUtrera]

En efecto yo quiero que CocheAutomatico que tendrá una variable Conductor conductor, pero indicar que sólo pueda ser de ese tipo (ConductorAutomatico) (en un futuro podría cambiar y para no impactar en el modelo) y la idea es no sobrescribir.

¿Cuándo se cree la instancia debería ser: Conductor conductor = new ConductorAutomatico(); ?

Gracias por la respuesta!!!

Un saludo.

[Xerelo]

Creo que no me has entendido,

1. NO puedes tener una referencia Conductor conductor y hacer que acepte sólo ConductorAutomatico, aceptará cualquier clase que herede de Conductor.

Lo que puedes hacer es que Coche tenga un atributo Conductor privado, de forma que sólo admita un conductor mediante un método set. Después en CocheAutomatico sobreescribes el set de forma que rechace cualquier Conductor que no sea ConductorAutomatico.

¿Cuándo se cree la instancia debería ser: Conductor conductor = new ConductorAutomatico(); ?

Esto es correcto, pero no tiene que ver con lo que buscas. Si CocheAutomatico hereda de Coche, hereda también el Conductor conductor, y volvemos al punto 1.

[wigglyUtrera]

Hola, la verdad es que sí me está siendo de utilidad lo que comentas.

Puesto que los atributos son privados, Conductor conductor no hereda, si no que hereda el get/set que estarían sobrecargados.

... aunque si sobrecargo el get/set de CocheAutomatico, tendría que tener un atributo conductor de tipo ConductorAutomatico (que es lo equivalente a una relación entre CocheAutomatico y ConductorAutomatico)

¿Es correcto esta doble relación? Es decir, tanto a nivel Coche --> Conductor y CocheAutomatico --> ConductorAutomatico

Gracias!!

Un saludo.

[Xerelo]

... aunque si sobrecargo el get/set de CocheAutomatico, tendría que tener un atributo conductor de tipo ConductorAutomatico (que es lo equivalente a una relación entre CocheAutomatico y ConductorAutomatico)

No, aunque Conductor conductor sea privado, existe en tu objeto CocheAutomatico. No es accesible directamente pero sí mediante el get/set. Si añades una referencia ConductorAutomatico, tendrás un atributo Conductor vacío (lógico) y un ConductorAutomatico. Entonces ¿para qué heredar?

¿Es correcto esta doble relación? Es decir, tanto a nivel Coche --> Conductor y CocheAutomatico --> ConductorAutomatico

En principio NO si heredas, porque lo que tendrás será

Coche --> Conductor
CocheAutomatico --> Conductor

con el filtro en el set te puedes asegurar de que nunca reciba un Conductor que no sea ConductorAutomatico, pero no sé si teóricamente se considera equivalente a la relación que buscas. Funcionar funciona, el resto es un poco a qué huelen las nubes.

Me da la impresión de que partes de un mal planteamiento, si existe la clase Conductor es que quieres que haya una serie de clases conductor que comparten métodos comunes, y para eso te da igual que referenciar un objeto ConductorAutomatico como Conductor. Cuando quieras usar métodos específicos de ConductorAutomatico simplemente haces un cast a ConductorAutomatico (ya te aseguraste mediante el set que el conductor de CocheAutomatico es ConductorAutomatico).

[wigglyUtrera]

Sí, ¿pero el casting cómo lo especifico en el modelo?

La idea es representar en el modelo la información necesaria para el que tenga que hacer el código (como un plano para un albañil).