¿Hay alguna diferencia en términos de implementación, ya que un diseño de composición puede ser diferente de la delegación? Por ejemplo, el código siguiente parece estar haciendo delegación, ya que el usuario no puede acceder al objeto compuesto (es decir, "a") sin utilizar b. Por lo tanto, el usuario necesitaría invocar las interfaces de la clase b y luego la "clase b" invocaría las interfaces apropiadas de la "clase a", convirtiéndola en delegación. Esto tiene sentido ?Composición frente a Delegación
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
};
Si la composición implica que el niño no puede existir sin el contexto del padre, ¿no debería el usuario nunca crear un objeto de la clase compuesta? Por ejemplo, mi refinado, por ejemplo, sería clase A {amigo Clase B; privado: A() {}; void PrintStructure() {}; }; Clase B {public: void PrintStructure() {a.PrintStructure();} // delegate private: A a; // composición}; Ahora la clase B tiene clase A. Un usuario debe usar solo interfaces de clase B para cambiar el comportamiento de clase A y la clase B debe delegar tales tareas a funciones de clase A. ¿Este diseño es bueno? –
@Frank: las clases de amigos son una forma de implementar este tipo de relación. Aunque no son un favor. Una solución más elegante es hacer que el constructor de Room requiera una instancia de House, que luego se convierte en su "padre". – cletus
¿Cómo codificaría algo así en mi ejemplo? Además, no quiero que el usuario pueda crear una instancia de un objeto de A, ya que no tendría sentido realizar ninguna operación en A sin el contexto de B. –