¿De qué sirve Asociación, Agregación y Composición?

He revisado muchas teorías sobre lo que es la encapsulación y las tres técnicas de implementación, que son Asociación, Agregación y Composición.

Lo que encontré es :

Encapsulamiento

La encapsulación es la técnica de hacer que los campos de una clase sean privados y proporcionar acceso a los campos a través de métodos públicos. Si un campo se declara privado, nadie puede acceder a él fuera de la clase, ocultando así los campos dentro de la clase. Por esta razón, la encapsulación también se conoce como ocultación de datos.

La encapsulación se puede describir como una barrera protectora que impide que el código y los datos sean accedidos aleatoriamente por otro código definido fuera de la clase. El acceso a los datos y al código está estrictamente controlado por una interfaz.

El principal beneficio de la encapsulación es la capacidad de modificar nuestro código implementado sin romper el código de otros que usan nuestro código. Con esta característica, la encapsulación brinda mantenibilidad, flexibilidad y extensibilidad a nuestro código.

Asociación

La asociación es una relación en la que todos los objetos tienen su propio ciclo de vida y no hay un propietario. Tomemos un ejemplo de profesor y alumno. Varios estudiantes pueden asociarse con un solo maestro y un solo estudiante puede asociarse con múltiples maestros, pero no hay propiedad entre los objetos y ambos tienen su propio ciclo de vida. Ambos pueden crear y eliminar de forma independiente.

Agregación

La agregación es una forma especializada de asociación donde todos los objetos tienen su propio ciclo de vida, pero hay propiedad y un objeto secundario no puede pertenecer a otro objeto primario. Tomemos un ejemplo de departamento y maestro. Un solo maestro no puede pertenecer a varios departamentos, pero si eliminamos el departamento, el objeto del maestro no se destruirá. Podemos considerarlo como una relación "tiene-a".

Composición

La composición es nuevamente una forma especializada de agregación y podemos llamar a esto como una relación de "muerte". Es un tipo fuerte de agregación. El objeto secundario no tiene su ciclo de vida y si el objeto primario se elimina, todos los objetos secundarios también se eliminarán. Tomemos nuevamente un ejemplo de relación entre la casa y las habitaciones. La casa puede contener varias habitaciones, pero no hay una vida independiente de una habitación y ninguna habitación puede pertenecer a dos casas diferentes. Si eliminamos la casa, la habitación se eliminará automáticamente.

La pregunta es:

Ahora todos estos son ejemplos del mundo real. Estoy buscando alguna descripción sobre cómo usar estas técnicas en el código de clase real. Me refiero a cuál es el punto de usar tres técnicas diferentes para la encapsulación , cómo podrían implementarse estas técnicas y cómo elegir qué técnica es aplicable en ese momento.

La distinción entre asociación, agregación y composición tal como la describe es un legado que se remonta a los viejos tiempos de la gestión manual de la memoria. Por ejemplo, en C ++, la memoria utilizada por los objetos debe liberarse manualmente y, por lo tanto, es fundamental diseñar cuidadosamente el ciclo de vida de los objetos compuestos. Si bien la distinción entre agregación y composición todavía se enseña en muchos libros de texto, es esencialmente irrelevante cuando se programa en entornos con administración automática de memoria. Si tiene recolección de basura, todos ellos son solo composición, punto.

La encapsulación, por otro lado, es un principio mucho más general que lo que usted describe. Es ante todo la idea de agrupar datos y las funciones que operan en estos datos en un módulo. Una forma de implementar esto es mantener el estado del módulo privado y exponer los cambios a ese estado a través de los servicios públicos. Por lo tanto, el cliente no puede acceder al estado por sí solo, pero tiene que comunicarle al módulo su intención enviando mensajes. Por lo tanto, la encapsulación no se limita a los objetos, sino que también se aplica a los servicios. En realidad, una forma de mirar los objetos es mirarlos como servicios.

Aquí hay un ejemplo de encapsulación

public class Counter {
    private int n = 0;
    public int inc() { return n++; }
}

o lo mismo usando funciones lambda

var counter = (function() {
    var n = 0;
    var inc = function() { return n++; }
    return inc;
})();

En ambos casos, los datos, que es la variable n, se agrupan junto con la función incque opera en ellos. Y no hay forma de que alguna otra función pueda acceder n, por lo tanto, tenemos un módulo encapsulado que proporciona el conteo como un servicio.

NB: exponer todo el estado interno de un objeto a través de accesores es en realidad una violación de la encapsulación. Por desgracia, es una violación tan común que muchos lo confundirán con un buen diseño orientado a objetos.

La encapsulación es la técnica de hacer que los campos de una clase sean privados y proporcionar acceso a los campos a través de métodos públicos. Si un campo se declara privado, nadie puede acceder a él fuera de la clase, ocultando así los campos dentro de la clase. Por esta razón, la encapsulación también se conoce como ocultación de datos.

    public class Test{

    private String name;

       private int age;

       public int getAge(){
          return age;
       }

       public String getName(){
          return name;
       }
    }

Consulte esta pregunta también .

La asociación indica la relación entre los objetos. Por ejemplo: la computadora usa el teclado como dispositivo de entrada.

Una asociación se usa cuando un objeto quiere que otro objeto realice un servicio para él.

La agregación es un caso especial de asociación. Una asociación direccional entre objetos. Cuando un objeto 'tiene-a' otro objeto, entonces tiene una agregación entre ellos.

Por ejemplo: la habitación tiene una mesa, pero la mesa puede existir sin la habitación.

    class Room {

      private Table table;

      void setTable(Table table) {
        this.table = table;
      }

    }

La composición es un caso especial de agregación. La composición es más restrictiva. Cuando hay una composición entre dos objetos, el objeto compuesto no puede existir sin el otro objeto. Esta restricción no existe en la agregación. por ejemplo: habitaciones en una casa, que no pueden existir después de la vida útil de la casa.

    class House {

      private  Room room;

      House(Room roomSpecs) {
        room = new Room(roomSpecs);
      }

    }

La composición es una técnica de diseño para implementar una relación has-a en las clases, ya sea por herencia o por composición de objeto para reutilizar el código.

Una de las mejores prácticas en la programación Java es usar la composición sobre la herencia

El uso de esas técnicas generalmente da como resultado prácticas de diseño como SOLID o varios patrones de diseño .

El objetivo de usar patrones, prácticas y demás es describir una solución a un problema específico que también sea mantenible y extensible. Simplemente necesita obtener suficiente experiencia para saber dónde usar qué patrón o técnica.

Francamente, siento que estas nociones que se enseñan en el ámbito académico tienen su importancia en los contextos de orientación a objetos y diseño de clase. Estos conceptos nos ayudan mucho a la hora de modelar un sistema desde cero. La asociación, la agregación y la composición pertenecen exclusivamente al diagrama de clases de UML y son completamente independientes de las limitaciones tecnológicas, como los problemas de memoria.

Además, también debe considerar el nivel superior o los objetivos comerciales del sistema que está modelando. Tenemos objetos como House y Room en nuestro sistema bajo consideración, pero no pueden estar fuertemente relacionados (a través de la composición). Por ejemplo, si estoy modelando un sistema inmobiliario, entonces podría tener que saber qué habitación pertenece a qué casa. Pero permita que esté modelando un sistema de encuesta o censo donde quiero saber cuántas personas viven en cada habitación de la casa en un área determinada, entonces no necesito relacionar una habitación con una casa a través de la composición.

Otro ejemplo podría ser de un huerto y cierto tipo de fruta. Digamos que solo puedo considerar un huerto cuando tengo manzanos plantados en su interior. La conclusión es que los requisitos del sistema general son muy importantes.

La encapsulación es uno de los pilares del diseño orientado a objetos. Debe agrupar sus datos y las operaciones que realizará en sus datos. También debe ocultar ciertos atributos de su objeto del mundo exterior para permitir que ese objeto sobreviva en un estado válido. Cuando 2 objetos están interactuando, tienen que interactuar entre sí a través de una interfaz. Y eso es lo que garantiza la encapsulación cuando diseñamos nuestro sistema OO.

Así es como se aplican estos conceptos al código:

ASOCIACIÓN: Asociación indica la relación entre objetos. Le permite al programador saber qué métodos escribir en sus clases para que interactúen entre sí. Puede encontrar varios ejemplos de diagramas de código y clase para comprender la asociación. En su ejemplo de Teach and Student, hay una relación de enseñanza y enseñada por . Por lo tanto, simplemente escribirá un conjunto de métodos (técnicamente llamado interfaz) a través del cual puede conocer qué estudiante tiene qué maestros y qué maestro tiene qué estudiantes. La asociación también permite que el modelador del sistema ayude al diseñador de la base de datos sobre los atributos y campos que deben mantenerse en la base de datos.

COMPOSICIÓN: si un objeto es una parte integral de otro objeto, entonces podría tener que indicar esta relación en el constructor del otro objeto. Por ejemplo, en su escenario de Casas y habitaciones, podemos escribir el siguiente código en caso de que queramos saber qué habitación pertenece a qué tipo de casa.

class House{
          string _HouseType;   
     public:    
    void setHouseType(string house_type)
     {
        this. _HouseType = house_type;
     } 

     string getHouseType()
    {
       return _HouseType;
    }
};



 House HouseObject = new House();


class Room{

 public: 
 Room(string HouseType) {
       this._HouseType = HouseObject.getHouseType();  //as in my system a room cannot exist without a house

 } 

};

El programador también se asegurará al invocar a los destructores del objeto, que también se invoque el destuctor del otro objeto. Esto es crucial

AGREGACIÓN: Digamos que si la relación entre los objetos es débil, entonces para el programador, significaría usar una variable de instancia para indicar la relación. Y luego escriba un functon mutador (setter) para proporcionar valor a ese objeto desde otro.

class Department{

 string dept_name;

public:
   void setDeptName(string name)
   {
        this.dept_name=name;
   }

   string getDeptName()
   {
        return dept_name; 
   }

};



 Department DepartmentObject = new Department();

class Teacher{

 string dept_name;

public:

  setDeptName(string name)
  {
     this.dept_name = DepartmentObject.getDeptName();  //You only need to invoje this method when needed (aggregation)
  }
}

};

Bien, asignemos esto a algunas propiedades centrales en lugar de conceptos abstractos que solo tienen sentido una vez que entiendes lo que significan. Al igual que algunos comentaristas, no estoy de acuerdo con la respuesta aceptada, digo que estos son conceptos independientes de la administración de la memoria.

Encapsulamiento

Desea ocultar la complejidad del cliente, solo publicando las cosas que importan desde el punto de vista del cliente, haciendo las cosas más fáciles para el cliente. Como beneficio adicional, tiene la certeza de que nada puede interferir con el código encapsulado. Siempre que respete la interfaz y la funcionalidad, puede volver a trabajar y tener la seguridad de que no romperá nada. La dependencia está solo en la interfaz publicada.

La encapsulación es uno de los principales pilares de la orientación a objetos. No es un patrón, es un principio y puede aplicarse tanto a la lógica como a los datos. Es solo un beneficio básico de usar clases en primer lugar, no es algo que vería explícitamente en un diagrama o documento de diseño.

Asociación

Este es un concepto muy laxo que básicamente describe solo una dependencia entre objetos. Un objeto conoce la existencia de otro objeto y puede usar su funcionalidad en algún momento. En un diagrama, la asociación lo alertaría de que existe una dependencia y que cambiar un objeto puede afectar al otro. No es una técnica para aplicar cuando tiene algún problema que resolver, es más como un hecho de la vida que debe tener en cuenta cuando está allí. Es una relacion. Como una factura que tiene una propiedad de pedidos. Tanto la Orden como la Factura tienen su propio ciclo de vida. Uno es sobre bienes y el otro sobre pagos, lo que esencialmente los hace independientes, pero es importante saber qué bienes se están pagando.

Contención

Estoy agregando esto porque pertenece a la serie y hará que la agregación sea más significativa. Ya no escucho mucho el término que se usa en un contexto SE, pero creo que sigue siendo útil. La contención implica encapsulación, pero se trata estrictamente de instancias de objeto privadas para la clase que lo contiene. La funcionalidad de los objetos contenidos se expone selectivamente a través de interfaces públicas. La clase que contiene controla el ciclo de vida de los objetos controlados. Usas esto cuando necesitas algunas características de una clase existente para hacer que la clase que contiene sea funcional. Esto podría ser un analizador XML y el cliente de la clase que lo contiene nunca puede ver o saber nada relacionado con XML. Como metáfora, piense en el objeto contenido como un empleado de back office. Los clientes nunca conocen a estas personas, sin embargo, son necesarios para proporcionar el servicio.

Agregación

Esto es muy parecido a la contención, excepto por el control del ciclo de vida y la visibilidad de los objetos agregados. Los objetos agregados ya están disponibles en un contexto diferente y son administrados por una entidad diferente. El agregador simplemente ofrece una fachada, un portal a los objetos agregados. Cuando el cliente se dirige al agregado, obtiene la interfaz del objeto agregado en sí, no un envoltorio a su alrededor. El objetivo del agregado es ofrecer una agrupación lógica de cosas. Piense en un punto de acceso a servicios u otro objeto contenedor.

Composición

Me parece que este es el término más contemporáneo para la contención, posiblemente porque fue acuñado en un libro popular de origen relativamente reciente. Cuando la contención se centra en los aspectos técnicos de las relaciones de objeto, la composición se usa típicamente en el contexto de las decisiones de diseño, más específicamente como una alternativa más flexible para la herencia.

No dice mucho acerca de la naturaleza de las relaciones o propiedad de los objetos, simplemente indica que la funcionalidad se implementa combinando la funcionalidad de las clases existentes. Por lo tanto, diría que no pertenece a esta serie porque no dice nada sobre los aspectos técnicos de una implementación donde los demás sí.