Voilà, au cours d'un diner, un pote m'a lancé un petit défit (que l'écriture d'un compilo lui a inspiré).
 
On a un arbre (binaire, pour pas se faire chier), qu'on va transformer en un autre arbre (au cours d'une passe de compilation par ex.).
Bien entendu, sur aucun des 2 arbres on a d'accesseur en écriture.
On a uniquement des constructeurs et des accesseurs en lecture pour les noeuds et les feuilles.
Dans le nouvel arbre construit, on a une référence dans chaque noeud à son noeud parent (à l'exception de la racine).
Il n'est pas question de filer une référence à quelqu'un sur un objet qui n'est pas dans un état respectant l'invariant (en gros pas question de tenter de finir la construction plus tard, sinon violation de l'invariant).
 
Vous pouvez supposer que l'arbre de départ possède déjà des pointeurs vers le parent (mais ça ne vous servira probablement pas).
 
Hint : il n'est pas sûr que tous les langages permettent de le faire, je l'ai fait en Objective Caml, mon pote en Smalltalk, ça doit être faisable, en en chiant un peu, en C++, C# et java ; ruby et python devraient aller.
 
Note : non, c'est pas mon devoir, je suis pas sûr que mes profs seraient capables de faire ça.
 
edit : la question est bien entendu d'écrire le code construisant le nouvel arbre à partir de l'ancien.

Et c'est quoi la question ?

moi je dirais plutot au cour d(un cours (non d un diner) un prof (et non un ami) a lancé un devoir ...

tu t'éclates pendant tes diners entre potes toi

Sérieusement, tu t'estimes meilleur que t profs !?

 
En fait, la solution à ton problème est très simple !
 
Tu créé un pointeur pour chaque référence d'accesseur présent dans chaque branche de l'arbre. Ceci te permet de créér une classe virtuelle qui te permettra de créer unc copie bit à bit de la branche ne possédant pas de fils et ainsi de passer outre les règles de polymorphisme propre à la POO, en faisant du pseudo-procédural de la manière la plus simple qui soit.
 
Tu vas me dire que l'utilisation de classes et méthodes virtuelles ne permettra pas d'hériter directement du noeud fils, étant donné que le fait de déclarer des classes amies casse toute la structure objet de ton arbre, ceci étant provoqué par un unboxing bourrin des variables membres de la classe associée (qui dérive bien évidemment de la classe abstraite créée précédemment). Mais tu oublies que l'utilisation d'interfaces te permet d'appliquer toutes les règles de polymorphisme définies plus haut comme s'il s'agissait de classes abstraites définies normalement.
 
La prochaine fois, pose des questions plus compliquées ! Y'a longtemps que je ne suis plus en 6ème
 

 
mouais moyen ce coup ci, fodrait voir a t'entrainer tu perds la main

normal, je suis prof !

Le pire c'est que t'es pas loin de la réalité, le pote en question est un ancien intervenant avec qui on va se prendre une mine et parler info une fois de temps-en-temps.

ca explique le sujet que tu proposes alors  

Ceci-dit, c'est un problème qu'on rencontre super-souvent en compilation, voir en info en général. La technique classique consiste à pêter le contrat et à ne renseigner soit les enfant soit le parent d'abord et l'autre enssuite. Mais c'est mal.

mais c'est simple et ca marche

un temps

 
de toute facon tout est voue  l'echec dans cette vallee de larmes

La soluce repose tout simplement sur la fainéantise. (j'aime bien dire ça, ça sous-entend que c'est évident, alors que si on m'avait pas mis sur la voie, je serais encore en train de chercher).
 

 
Pour ceux qui ne conaissent pas le lazy, c'est une expression stockée sous forme non évaluée.
notation :

)
 elle ne sera évaluée que si c'est nécessaire (par Lazy.force).

est en fait le type

(une fonction qui prend l'unité () en paramètre et qui renvoie un 'a)

est l'équivalent de  

passer l'unité en paramètre à la fonction (donc l'évaluer).
et  

 
est transformé syntaxiquement (grace à camlp4) en  

 
Voilou.