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

Tengo una situación en la que mi padre sabe de 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 WeakReference en el niño para referirme al padre, pero creo que agrega una sobrecarga molesta, pero tal vez sea la mejor manera de hacerlo.

¿Es solo una mala idea? ¿Cómo implementaría esta habilidad de manera diferente?

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

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

¿Es solo una mala idea?

A menudo.

• Rompe la encapsulación del padre.
• Aumenta el acoplamiento en ambos.
• Sirve como punto de arranque para el niño para llegar al resto del sistema, lo que aumenta el acoplamiento con algo vagamente cerca de él (porque las personas van a abusar de esa referencia)
• Limita su diseño si alguna vez quiere niños sin padres.

¿Cómo hacerlo mejor? El niño no debe saber ni preocuparse de que esté en una colección. En lugar de considerarse importante, debe indicar que algún evento que conoce ha sucedido para que a quien le importe (el padre) pueda aumentar su prioridad (o cualesquiera que sean las reglas para el contexto en el que vive el niño). Eso no me entusiasma, y ​​tal vez preferiría una mejor separación de las preocupaciones entre el modelo del niño y el comportamiento de importancia, pero no puedo elaborar sin más contexto.

[editar:]

Sí, los sistemas de representación son un caso en el que la propiedad de los padres ... bueno, no quiero decir que tenga sentido, pero es un caso en el que 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) camina por el árbol y sabe qué colección reordenar en lugar de encontrar al niño, llamando a algo que sabe ir a su padre.

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

p.ej. 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();
    }
}

podrías cambiarlo a

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

No creo que sea una mala idea. Puede resolver esto agregando un valor de orden de clasificación a cada elemento secundario. Estoy imaginando algo como el "índice z" utilizado para mostrar objetos uno encima del otro o detrás de ellos en las páginas web.

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