java - objetos - herencia uml

Distinguir entre delegación, composición y agregación(Java OO Design)

Question

Me enfrento a un problema continuo que distingue la delegación, la composición y la agregación entre sí, y la identificación de los casos en que es mejor utilizar uno sobre el otro.

He consultado un libro de análisis y diseño de Java OO, pero aún persiste mi confusión. La explicación principal es esta:

Delegación : cuando mi objeto utiliza la funcionalidad de otro objeto como está sin cambiarlo.

Composición : Mi objeto consiste en otros objetos que a su vez no pueden existir después de que se destruye mi objeto: basura recolectada.

Agregación : Mi objeto consiste en otros objetos que pueden vivir incluso después de que se destruye mi objeto.

¿Es posible tener algunos ejemplos simples que demuestren cada caso y el razonamiento detrás de ellos? ¿De qué otro modo se pueden demostrar estos ejemplos, aparte de que mi objeto simplemente tiene una referencia a otro (s) objeto (s)?

Answer 1

Delegación

public class A {
  private B b = new B();

  public void methodA() {
    b.methodB();
  }
}

Cuando los clientes de A invocan el methodA , la clase A delega la llamada al methodB B de methodB

Razón fundamental. La clase A expone comportamientos que pertenecen a otra parte. Esto puede suceder en lenguajes de herencia única donde la clase A hereda de una clase, pero sus clientes necesitan comportamientos que se implementan en una clase diferente. Estudio adicional .

Delegación Híbrida

public class A {
  private B b = new B();

  public void methodA() {
    b.methodB( this );
  }
}

La diferencia entre la delegación que implica el envío simple y la delegación que actúa como un sustituto de la herencia es que el destinatario debe aceptar un parámetro de la persona que llama, ejemplificado como:

    b.methodB( this );

Razón fundamental. Permite que las instancias de clase B utilicen la funcionalidad disponible de la clase A , tal como lo haría la clase B si heredara de la clase A pero sin herencia. Estudio adicional .

Composición

public class A {
  private B b = new B();

  public A() {
  }
}

Una vez que no existen más referencias a una instancia particular de clase A , se destruye su instancia de clase B

Razón fundamental. Permite a las clases definir comportamientos y atributos de forma modular. Estudio adicional .

Agregación

public class A {
  private B b;

  public A( B b ) {
    this.b = b;
  }
}

public class C {
  private B b = new B();

  public C() {
    A a = new A( this.b );
  }
}

Una vez que no haya más referencias a una instancia particular de clase A , su instancia de clase B no se destruirá. En este ejemplo, tanto A como C deben ser recolectados antes de que B sea ​​destruido.

Razón fundamental. Permite instancias para reutilizar objetos. Estudio adicional .

Demostración sin referencias

Los nombres dados a estos patrones simples se definen por sus relaciones referenciales.

Answer 2

1) Delegación: ejemplo de Man-driver-car. Un hombre compró un auto. Pero ese hombre no sabe conducir el auto. Entonces nombrará un conductor que sepa conducir un automóvil. Entonces la clase Man quiere realizar un transporte usando el automóvil. Pero no tiene la funcionalidad interactiva / compatibilidad con el automóvil. Entonces él usa una clase que tiene compatibilidad con el coche que es un controlador que es compatible con la clase de hombre. Suponiendo que el conductor pueda entender lo que dice el hombre

2) Composición: la simulación de coches es un ejemplo de rutina. Para hacer que un automóvil se mueva, la rueda gira. La clase de automóvil que usa la clase de rueda gira la funcionalidad como parte de su función de movimiento, donde la rueda forma parte del automóvil.

3) Agregación: Coche y su color. Objeto de clase de coche ferrari tendrá un objeto de clase de color rojo. Pero el objeto de clase de color rojo puede estar allí como clase individual, cuando la búsqueda del usuario ocurre con una especificación de color rojo.

Answer 3

Su objeto haría referencia a otro (s) objeto (s) en los tres casos. La diferencia radica en el comportamiento y / o ciclo de vida de los objetos a los que se hace referencia. Algunos ejemplos:

1. Composición: House contiene una o más habitaciones. La vida de la habitación está controlada por House, ya que Room no existiría sin House.

2. Agregación: casa de juguete construida de bloques. Puedes desmontarlo pero los bloques permanecerán.

3. Delegación: Su jefe le pidió que le llevara un café, en cambio, lo hizo por un interno. La delegación no es un tipo de asociación (como la composición / agregación). Los últimos dos han sido discutidos en muchas veces

En el comentario se pregunta cómo diferiría la implementación en cada caso, observando que en todos los casos invocamos métodos en los objetos relajados. Es verdad que en cada caso tendríamos código como

myRoom.doWork();

myBlock.doWork();

myMinion.doWork();

pero las diferencias radican en el ciclo de vida y la cardinalidad de los objetos relacionados.

Para el Componente, las Salas entran en existencia cuando se crea la Casa. Entonces podríamos crearlos en el constructor de la casa.

En el caso de la Asociación (voy a usar neumáticos y automóviles), los automóviles pueden agregar neumáticos en su constructor, pero más adelante es posible que desee eliminar y cambiar los neumáticos. Entonces también tienes métodos como

 removeTyre(FrontLeft)
 addNewTyre(aTyre, BackRight)

Y es bastante probable que el objeto aTyre provenga de una fábrica; no lo hemos actualizado en ninguno de los métodos del automóvil.

En el caso de Delegación, es posible que ni siquiera tenga una variable miembro para retener al delegado

 resourcingPool().getIntern().getCoffee(SkinnyLatte, workstation 7);

la relación entre los objetos dura solo mientras el interno esté buscando el café. Luego vuelve al grupo de recursos.

Answer 4

Tu libro explica bastante bien, así que déjame elaborar y darte algunos ejemplos.

delegación: cuando mi objeto usa la funcionalidad de otro objeto como está sin cambiarlo.

En algún momento una clase puede lógicamente necesitar ser grande. Pero la clase grande no es una buena práctica de codificación. También en algún momento, algunas funcionalidades de una clase pueden implementarse en más de una forma y es posible que desee cambiar eso en algún momento.

class FeatureHolder {
 void feature() {
  // Big implementation of the feature that you dont want to put in the class Big
 }
}

class Big {
 private FeatureHolder FH = new FeatureHolder();

 void feature() {
  // Delegate to FeatureHolder.
  FH.feature();
 }

 //.. Other features
}

Desde el ejemplo anterior, Big.feature () llama a la característica de FH tal cual sin cambiarla. De esta forma, la clase Big no necesita contener la implementación de la función (separación de trabajo). Además, feature () puede implementarse de manera diferente por otra clase como "NewFeatureHolder" y Big puede optar por usar el nuevo titular de la característica en su lugar.

composición: Mi objeto consiste en otros objetos que a su vez no pueden existir después de que mi objeto es desensilado: se recoge la basura.

Agregación: Mi objeto consiste en otros objetos que pueden vivir incluso después de que se destruye mi objeto.

Técnicamente, la composición es "parte de" y la agregación es una relación de "referencia". Tus brazos son parte de ti. Si ya no vives, tu brazo también morirá. Tu tela no es parte de ti, pero tú la tienes; como puedas invitado, tu ropa no te acompaña.

En la programación, algunos objetos son parte de otro objeto y no tienen ningún significado lógico sin él. Por ejemplo, un botón está compuesto por un marco de ventana. Si un marco está cerrado, el botón ya no tiene motivos para estar cerca (Composición). Un botón puede tener referencia a una base de datos (como para actualizar los datos); cuando se elimina el botón, la base de datos aún puede estar cerca (Agregación).

Perdón por mi inglés, espero que esto ayude