composition - siguientes - Composición vs. Delegación
relacion de tipo agregacion (3)
¿Hay alguna diferencia en términos de implementación en cuanto a cómo un diseño de composición puede ser diferente de la delegación? Por ejemplo, el código a continuación parece estar haciendo una delegación ya que el usuario no puede acceder al objeto compuesto (es decir, "a") sin usar b. Por lo tanto, el usuario necesitaría invocar interfaces de clase b y luego "clase b" invocar interfaces apropiadas de "clase a" para hacerla delegación. Esto tiene sentido ?
Class A {
friend class B;
private:
A(){}; //dont want user to instantiate this class object since it wont sense without any context. Just like a room with no house.
void PrintStructure(){};
};
Class B{
public:
void PrintStructure(){a.PrintStructure();} //delegate
private:
A a; //composition
};
El término "composición" se usa generalmente en términos de modelado de objetos como una expresión de una relación "has-a" y es una forma de asociación (otra es la agregación). Esto generalmente se contrasta con la "herencia" (relación "is-a"). Asi que:
¿Cuál es la diferencia entre composición y agregación? La composición implica que el hijo no puede existir sin el contexto del padre.
Por ejemplo, una casa tiene una o más habitaciones. Esa es una relación de composición. Eliminar la casa y las habitaciones también dejan de existir. Una casa también tiene un número de ocupantes, siendo instancias de la persona. Esa es una relación de agregación porque esas personas existen fuera del contexto de esa casa.
La delegación no es más que un detalle de implementación. Una clase tiene una interfaz pública que describe su estado y comportamiento. Cómo se implementa eso es irrelevante. Se podría delegar a otros objetos o no.
Notará que tanto A como B de su ejemplo tienen la misma interfaz externa. Es más común hacer algo como esto:
// this represents an interface
class A {
public:
virtual void printStructure() = 0;
}
con clases concretas:
class ConcreteA : A {
public:
virtual void printStructure() { ... }
}
y
class DelegateA : A {
public:
DelegateA(A& a) { this.a = a; }
virtual void printStructure() { a.printStructure(); }
private:
A a;
}
Disculpe mis errores de sintaxis C ++ probablemente. Estoy un poco oxidado.
Hay un par de diferencias que veo:
- La delegación involucra métodos de reexportación; en una relación de composición, los métodos de los objetos internos se pueden usar solo de forma privada y no se deben volver a exponer.
- La composición generalmente implica algún tipo de semántica de propiedad con implicaciones para el ciclo de vida del objeto; el objeto primario "posee" al niño y el niño no tiene muchas razones para existir por sí solo. La delegación no tiene esta implicación.
El código que muestres utiliza delegación y asociación; la asociación puede ser composición, pero es difícil decirlo sin un contexto más amplio o más información sobre los objetos (puede ser bastante sutil y subjetiva cuando una asociación se convierte en una composición).
La composición es sobre las relaciones entre los objetos.
La delegación se trata de pasar el trabajo de un objeto a otro.
Estas son preocupaciones realmente diferentes (pero a veces relacionadas).
Lo que tienes es B compuesto de A (B se refiere a A). B también delega su único método a A.
Pero dado que el uso de A por parte de B es privado (completamente encapsulado dentro de la caja negra de B), no llamaría "composición" al uso de A por parte de B. Yo usaría "composición" solo si se pudiera acceder a la clase A desde B. Lo que es importante aquí es si el modelo lógico de B tiene "una" A.
En su caso, B se implementa en términos de A. Dado que se trata de un problema de implementación, puede considerarse que no forma parte del modelo lógico de B. Es decir, puede hablar inteligentemente sobre B sin hablar o preocuparse por A.
Dicho todo esto, esto solo es realmente importante para las herramientas de modelado UML y PHB. O quizás si estás estudiando patrones de diseño. No me pondría demasiado nervioso.
[PHB => Jefe de pelo puntiagudo]