[JAVA] ¿Como implementar las relaciones entre clases?

Hola!!

Una forma de obtener código que ejemplifique las distintas relaciones (herencia, agregación, composición, multiplicidad, etc) es crear un diagrama de clases en algún programa especializado como (Visio, RationalRose, etc) y luego generar el código fuente automáticamente. Estos programas suelen implementar esta funcionalidad.

Te adjunto unos PDF con ejemplos de código para las distintas relaciones.
Suerte!!

de paso le hecho una hojeada yo tambien a esos pdfs.

gracias por el aporte nowhere

SaluT

De esos softwares hay muchos y muchos, Yo recuerdo que use varios de ellos, para Java.

Para los que quieren explorar un poco mas sobre el tema busquen sobre ingenieria reversa de software a partir de diagramas UML. Algunas aplicaciones que pueden hacer eso son: Rational Rose, Rational XDE Modeler, IBM Rational Software Architect, Visual Paradigm for UML 2.0, y ahora NetBeans 5.5 Beta 2 con su Netbeans Enterprise Pack viene incorporado un buen editor de diagramas UML con generacion de codigo.

Saludos
PABLO

Justamente lo que no quiero es usar ese tipo de programa. No existe ninguno, o por lo menos no los conozco. DE conocimiento mio el unico que conocia para java era Entreprise Architect.
Pero buscaba más explicitamene codigo.

Gracias, voy a leer los pdfs.

Si lo que necesitas es codigo, me parece que la respuesta a tu porblema esta en las interfaces

una interface es una declaracion que se hace en java que junta bajo una entidad una serie de metodos que hacen algo especifico.

Un ejemplo sencillo
vos tenes un auto..
El auto tiene varias interfaces,

Una para manejar que serian el volante y los pedales

Otra para servicio que seria ponele el medidor de aceite , la tapa del tanque de nafta y el tanque de agua.

Vos para manejar, una vez que conoces la interface de usar los pedales de freno y acelerador y el volante
podrias manejar cualquier cosa que tenga esa misma interface. tractor , camioneta , auto, etc etc..

O sea definis una clase y definir interfaces agrupando las operaciones estandares con la que la clase realiza, de forma que los objetos a la hora de "comunicarse" con el objeto , no miran la clase , si no la interface.

Vos podrias por ejemplo tener:
una clase socket
una clase archivo
una clase memoria

Esta 3 clases son capaces de abrri un canal (stream de datos para enviar informacion)
Usando herencia si o si ,estas clases deberian todas ser hijas de una clase llamada stream.
Muchas veces eso no es posible ya que en tu estrutura de objetos , el socket heredara de WindowsSocket y el archivo lo hara de WindowsFile por dar un ejemplo.

Ahora las 3 clases tienen en particular la capacidad de streamear datos
Entonces creamos una interfaces llamada IStream y definimos que la clase socket implementa esa interface. lo mismo file y memory.

A partir de ese momento vos instancias un objeto de cuelquiera de esas clases y podrias ponerlo en una variable el tipo IStream.
Y podrias usar ese objeto X , por medio del a interface iStream, sin importar la clase del objeto. Solo interesa que todos implementan la interface iStream.

Que se espero haber sido mas o menos claro.. si alguien lo explica mejor , mas didacticamente lo agradezco.

Creo que me entendiste mal o no me supe expresar.

El tema de uso de interfaces lo entiendo bien conceptualmente para implementar herencia multiple. Al igual que plasmar la herencia.

A lo que voy es que en un diagrama de clases por lo general hay relaciones mas fuertes que la simple que se genera en una clase main que hace de reunion para las clases. Sino que las clase por si sola necesita conocer a otra clase sin la necesidad de in "Extend" o un "implements".
A ese punto apunta mi consulta. Realizar las relaciones que son diferente a este tipo de relaciones.

Espero haberme expresado mejor ahora.

Creo que si bien vos hablas del diagrama de clases y las relaciones entre clases, creo que no te referis precisamente a la herencia en absoluto, sino que te referis a la composición de objetos, la agregación de objetos y al uso de objetos mediante el artifacto uml <<usage>>.

Bueno como verás la agregación y la composición son en si parecidos, nada mas que en la composición es la clase externa misma la que se encarga de manejar el ciclo de vida de los objetos que la componen, en cambio en la agregación no, los objetos que componen a nuestro otro objeto pueden existir fuera del ambito de vida de este.

Esto en java es muy facil de implementar, como? Facil mediante atributos de clase. Supongamos el clasico ejemplo de un auto:

Tenemos un objeto auto, un auto está compuesto por un motor, cuatro ruedas, y demás. Entonces nosotros podemos definir a los objetos de la siguiente forma:

(NOTA: Esto seria una composición ya que el objeto auto no puede vivir ni funcionar sin las ruedas, entonces el mismo es el encargado de manejar el ciclo de vida de los objetos rueda)

public class Car {

private List<Wheel> wheels = new ArrayList<Wheel>();
private Engine engine = new Engine();

public Car() {
super();

for( int counter = 0; counter < 4; counter ++) {
Wheel wheel = new Wheel(2);
wheels.add(wheel);
};

public List<Wheel> getWheels() {
return wheels;
}


public Engine getEngine() {
return engine;
}
};

Como verás ahi el objeto auto mismo creo una coleccion de objetos wheel y se encargo de crearlos el mismo, en este caso, es una composición 1 a muchos. Y se representa mediante una lista, un vector, un array y / o demás.

En caso de una agregación es simple, la idea seria la misma, solo que ahora los objetos agregados los recibe como parametro tanto en el constructor como en algun getter / setter.

Supongamos en este caso la idea de un camion de reparto de mercadería, tenemos un camion contiene 0 o mas cajones de mercaderia.

public class Truck {

private List<Wheel> wheels = new ArrayList<Wheel>(): //Esta es una composicion, el
//objeto camion no puede vivir sin ruedas

private List<Box> boxes = null; //Esta es una agregacion, el camion no se hace
//responsable de la creacion de las cajas que puede o no contener, las recibe por
//parametro


public Truck(List<Box> boxes) {
super();

for(int counter = 0; counter < 4; counter++) {
Wheel wheel = new Wheel(2);
wheels.add(wheel);
};

this.boxes = boxes;
}

public List<Wheel> getWheels() {
return wheels;
}

public List<Box> getBoxes() {
return boxes;
};

public void setBoxes(List<Box> boxes) {
this.boxes = boxes;
};
}:

Entonces en una clase main podemos tener

public class Delivery {

public static void main(String[] args) {

Truck truck = new Truck(null); //Por el momento no le asigno ninguna caja de
//mercaderia

//Creo caja de mercaderia
List<Box> boxes = new ArrayList<Box>();

boxes.add(new Box());
boxes.add(new Box());
boxes.add(new Box());

//Agrego las cajas al camion
truck.setBoxes(boxes);

return 0;
};
};

Saludos
PABLO

El tema de las interfaces sirve para suplir la herencia multiple, pero el concepto y el uso es distinto.
Mas alla de eso, tambien hablaron de agregacion y de Composicion de objetos

y

Al menos yo todavia no entiendo bien que es lo que queres hacer, ya que todos estos conceptos son mas bien conocidos.
Estamos hablando de teoria de programacion y me parece que vos buscar una respuesta practica , es un sensacion que tengo.

por eso , lo que queres hacer se puede plasmar en un ejemplo?

Saludos.

En principio la información que uno plasma en un diagrama de clases no necesariamente queda plasmada expresamente en el código (de la misma manera que todo lo que uno escribe en el código no queda plasmado en el diagrama de clases... o sino cuentenme cuantos de ustedes relacionan sus clases con java.lang.String en un diagrama). No hay que olvidarse nunca que los diagramas son una herramienta de documentación y no de generación de código.

Las relaciones de las que hablas (que no aparecen) son relaciones "no jerárquicas". Estas relaciones (como composición, agregación, etc) implican una relación funcional entre las clases, y no puede inferirse ninguna jerarquía a partir de ellas.
En principio las relaciones funcionales se pueden obtener/deducir observando los tipos de datos que contiene y/o procesa una clase (en principio, sus atributos y los parámetros y tipos devueltos de sus métodos te van a dar mucha de esa información, el resto se termina de deducir mirando el código).

Las relaciones jerárquicas son las que determinan los modificadores/keywords abstract, extends, implements, final, etc, y permiten establecer la relación entre las clases por abstracción, herencia y polimorfismo.

Saludos!,
Guido