Enlace de niño a padre: ¿mala idea?

15

Tengo una situación en la que mi padre sabe sobre su hijo (duh) pero quiero que el niño pueda hacer referencia al padre. La razón de esto es que quiero que el niño tenga la capacidad de designarse a sí mismo como el más importante o el menos importante cuando lo desee. Cuando el niño hace esto, lo mueve a la parte superior o inferior de los hijos de los padres.

En el pasado, he usado una propiedad de Referencia débil en el niño para referirme al padre, pero creo que eso agrega una sobrecarga molesta, pero tal vez sea la mejor manera de hacerlo.

¿Esto es solo una mala idea? ¿Cómo implementarías esta habilidad de manera diferente?

Actualización 1: Añadiendo más contexto. Este es un sistema de representación, por lo que el contenedor primario es una lista de ventanas agrupadas. El elemento secundario (ventana) que dice "¡Soy lo más importante!" básicamente quiere ser renderizado en la parte superior del resto de las ventanas.

El padre es solo un contenedor lógico para agrupar a estos hijos. Puedo ver dónde agregar un evento para indicar que la solicitud está en la parte superior es una buena idea. Pero aparte de la implementación (lo que el niño quiere hacer con el padre), ¿por qué no querría que el padre y el niño se vinculen? Las listas doblemente vinculadas hacen esto para que las personas puedan moverse hacia y desde algo.

    
pregunta Thraka 22.11.2012 - 03:33

3 respuestas

17
  

¿Es solo una mala idea?

A menudo.

  • Se rompe la encapsulación del padre.
  • Aumenta el acoplamiento en ambos.
  • Sirve como un punto de ruptura para que el niño llegue al resto del sistema, aumentando el acoplamiento con cualquier cosa vagamente cercana (porque la gente abusará de esa referencia)
  • Limita tu diseño si alguna vez quieres hijos sin padres.

¿Cómo hacerlo mejor? El niño no debe saber ni cuidar que se encuentra en una colección. En lugar de considerarse importante, debe indicar que algún evento que conoce ha ocurrido, por lo que a quien le importa (el padre) puede aumentar su prioridad (o cualquiera sea la regla del contexto en el que vive el niño). No estoy emocionado por eso, y tal vez preferiría una mejor separación de preocupaciones entre el modelo del niño y el comportamiento importante, pero no puedo elaborar sin más contexto.

[editar:]

Sí, los sistemas de renderización son un caso donde la propiedad de los padres ... bueno, no quiero decir que tenga sentido, pero es un caso donde se ha hecho y no es el fin del mundo. Para dar un enfoque de control, aún preferiría el diseño donde el manejador de entrada (o lo que sea) recorre el árbol y sabe qué colección reordenar en lugar de encontrar al niño, llamando a un elemento que sabe que debe dirigirse a su padre.

    
respondido por el Telastyn 22.11.2012 - 04:10
0

¿Cómo llegó la ejecución al punto en que el niño decide que quiere ser lo más importante? ¿Llegó a través de los padres? En caso afirmativo, podría enviar una referencia al padre a ese método.

por ejemplo. Si todos los nodos tienen algún tipo de método update () que hace algo como

void update() {
    doSomething()
    for(Node n:childs){
        //do something
        n.update();
    }
}

puedes cambiarlo a

void update(Node parent) {
    doSomething(parent)
    for(Node n:childs){
        //do something
        n.update(this);
    }
}
    
respondido por el user470365 22.11.2012 - 11:43
0

No creo que sea una mala idea. Podría resolver esto agregando un valor de orden de clasificación a cada niño. Estoy imaginando algo como el "índice z" que se usa para mostrar los objetos encima o detrás de los demás en las páginas web.

No estoy seguro de cómo codificarías algo así, pero el concepto parece factible.

    
respondido por el Michael Riley - AKA Gunny 22.11.2012 - 14:32

Lea otras preguntas en las etiquetas