Trouver programmatiquement l'instance d'un objet parent dont je suis une propriété

Version imprimable

20/07/2021, 12h00
Chavadam

Trouver programmatiquement l'instance d'un objet parent dont je suis une propriété
Bonjour.
J'ai une question portant sur Java; pas sur Swing, même si mon exemple en comporte des éléments de Swing.

Help ! Quelqu'un pourrait d'abord me dire : À part les tags [LIST] et [INDENT] pour établir une 'liste à bulles' avec différentes indentations, quel est le tag désignant qu'on passe à l'item suivant dans une liste ? Je corrigerai alors les deux listes suivantes.

À partir d'un objet 'b' (this), trouver par instructions la variable ou l'objet 'a' pour lequel 'a' constitue une propriété dans 'b' (= une variable d'instance).
(Non pas : Trouver à partir de l'objet 'b' (this) l'objet 'a' dont il hérite [super])

Soit la configuration (élaguée) suivante :
- Un panneau 'panneauÀOnglets2' de classe 'JTabbedPane' agrégeant [addPan()]
  deux panneaux 'tab_ÉnergÉlectr_TranchePuiss_2x'
  de classe propre 'ÉnergÉlectrParTranchePuiss'
  devant pouvoir fonctionner de manière autonome et comprenant chacun :
  
  un panneau 'panneauTteLaPage' de classe 'JPanel' agrégeant entre autres
  
  un panneau 'panneauDePanneauxÀUnOnglet'
  agrégeant trois panneaux, dont les deux suivants concernent le présent problème :
  
  'tabPan_ChoixMach' de classe propre 'TabPan_ChoixMach'
  contenant la méthode 'public byte getNbreMachChoisies()' qui intéresse d'autres objets dans d'autres branches.
  'tabPan_TtesCombMach' de classe propre 'TabPan_TtesCombMach'
  héritant de JPanel et contenant entre autres :
  
  'tablePrinc_TtesCombMach' de classe 'TablePrinc_TtesCombMach'
  héritant de JTable et faisant appel à 'ModèleTblPrinc_TtesCombMach'.
  
  un panneau à graphique ('panneauGraph' - Ne concerne pas le présent problème)
un panneau à graphique ('panneauGraph' - Ne concerne pas le présent problème)
Rem. Pour la simplicité, je n'ai pas mentionné les 'JScrollPane's.

[Je n'ai pas trouvé le moyen pour que l'éditeur affiche une bulle noire également au 2e item et plus ! Good grief]

Pour permettre à des méthodes propres à la 'tablePrinc_TtesCombMach' d'accéder au 'nbreMachChoisies' de l'objet 'tabPan_ChoixMach',
- soit je passe l'un des deux objets 'énergÉlectr_TranchePuiss' de la classe même 'ÉnergÉlectr_TranchePuiss' en argument
  (Méthode que j'emploie couramment) :
  
  au constructeur 'TabPan_TtesCombMach(ÉnergÉlectrParTranchePuiss énÉlecTranPuiss)'
  
  à 'modèleTblPrinc_TtesCombMach = new ModèleTblPrinc_TtesCombMach(énÉlecTranPuiss)'
  
  ...
- soit '(choixpuissmachcogén.monotone.machchoisies.ModèleTable_MachChoisies) énÉlecTranPuiss.getTabPnl_MachChoisies().getTable_MachChoisies().getModel()' .
- soit j'utilise un import de 'énÉlecTranPuiss'. (Méthode que j'emploie couramment)
Voici enfin ma question :
Plutôt que de transmettre 'énÉlecTranPuiss' par argument d'objet à objet (= ma méthode privilégiée n°2), y a- t-il des instructions de l'API de Java qui permettent de trouver l'objet parent de l'objet où l'on est, pour faire par une suite d'instructions le cheminement vers une variable (retournée par la méthode 'public getNbreMachChoisies()'), vers un objet cousin ('tabPan_ChoixMach') et la transmettre aux codes situés dans les objets 'TablePrinc_TtesCombMach' et 'ModèleTblPrinc_TtesCombMach' ?
Un peu comme 'super.', sauf qu'il ne s'agit pas ici d'héritage. Ou comme 'InstanceOf()'.
Mon exposé est assez clair ?

Merci d'avance pour vos éventuels essais de réponse
et à Développez.net pour son impressionnante offre et son précieux service.
27/07/2021, 16h45
joel.drigo
Salut,

Pour te répondre sur l'aspect "édition/rédaction", avec les listes, tu n'as pas besoin de te préoccuper des indentations.

[LIST]
[*]niveau 1
[*]niveau 1
[*]niveau 1

[LIST]
[*]niveau 2
[*]niveau 2

[LIST]
[*]niveau 3
[*]niveau 3
[*]niveau 3
[/LIST]

[*]niveau 2
[/LIST]

[*]niveau 1
[*]niveau 1
[*]niveau 1
[/LIST]

Affiche :
- niveau 1
- niveau 1
- niveau 1
  - niveau 2
  - niveau 2
    
    niveau 3
    niveau 3
    niveau 3
  - niveau 2
- niveau 1
- niveau 1
- niveau 1
En revanche, pour les puces, on est limité aux ronds noirs, aux listes de nombres, lettres (romaines minuscules/majuscules) et chiffres romains :

[LIST]
[*]niveau 1
[*]niveau 1
[*]niveau 1

[LIST=i]
[*]niveau 2
[*]niveau 2

[LIST=A]
[*]niveau 3
[*]niveau 3
[*]niveau 3
[/LIST]

[*]niveau 2
[/LIST]

[*]niveau 1
[*]niveau 1
[*]niveau 1
[/LIST]
- niveau 1
- niveau 1
- niveau 1
  1. niveau 2
  2. niveau 2
    
    niveau 3
    niveau 3
    niveau 3
  3. niveau 2
- niveau 1
- niveau 1
- niveau 1
Pour des puces graphiques, reste l'indentation, mais c'est bien se ~~faire c...~~ compliquer la vie, alors que les listes imbriquées me semblent suffisamment lisibles AMHA.

Par ailleurs, pour info, la doc des balises est ici.
27/07/2021, 16h57
joel.drigo
En ce qui concerne tes questions techniques, c'est moins clair.
1. J'ai l'impression que tu cherches à faire de la réflexion, mais est-ce pour faire un exercice sur la réflexion (ou introspection), ou pour faire de la programmation standard ?
  Parce que normalement, les objets n'ont pas à analyser les variables des autres objets, ou chercher leurs propre variables (ils y ont accès de par l'implémentation du langage), ou encore le parent (encore faut-il définir ce que ça pourrait bien être (je suppose ici que ce serait une instance d'objet qui pourrait avoir une référence vers l'objet dont on chercherait le parent, mais direct (par variable membre du type de l'objet), indirecte (par variables de composition, genre tableau, liste, map, ou autre séries d'objets encapsulés les uns dans les autres... et autre type de lien), surtout qu'une même instance d'objet peut être référencée par plusieurs objets, voire par lui-même, voire par aucun et encore exister en mémoire...).
  Je dis normalement parce que le principe même de base de l'objet est que ses variables ne devraient jamais être accédées que par lui-même (encapsulation/boite noire).
2. La réflexion permet dans une certaine mesure d'aller chercher les variables d'une classe, et d'évaluer pour une instance, les valeurs ou références qui y sont stockées, mais on l'utilise dans des cas très spécifiques (à moins que l'exercice porte sur la réflexion).
3. il n'est pas totalement impossible de trouver les objets qui référencent un objet donné, mais c'est plutôt compliqué, pour un intérêt limité dans le cas d'un runtime (en debug, profiling (ou usage de mbean pour scruter des datas de runtime), ou ce genre de choses, je dis pas, c'est utile... ).
  Après si le besoin est au niveau du runtime, c'est par la modélisation de la classe qu'un objet pourra connaître un parent par exemple, comme c'est le cas d'une classe de modélisation d'arbre (exemple Java javax.swing.tree.TreeNode et sa méthode getParent()).
28/07/2021, 09h46
Chavadam

Bonjour Joël.
Merci pour ta double réponse. Surtout celle sur la 'réflexion' ouvre mon horizon.
Concernant

Citation:

À partir d'un objet 'b' (this), trouver par instructions la variable ou l'objet parent 'a' pour lequel 'b' constitue une propriété (= une variable d'instance).

C'était pour moi un éclair de solution alternative, cherchant à éviter
° soit de multiplier les imports d'autres classes, celle contenant 'getNbreCol()' (pour trouver le 'nbreCol'),
° soit les longues désignation de cheminement précédant un 'getNbreCol()'
située dans une classe d'une autre branche de la bonne instanciation de 'tab_ÉnergÉlectr_TranchePuiss_2x'.
Mais 'getParent()' n'existe que rarement dans les API et conduirait aussi à un long cheminement -> Je dois oublier.
Sempiternel, mon remerciement, à toi et à Développez.net.

P.S.: Pour laisser à qui que ce soit un temps d'intervention, je n'actionnerai 'Résolu' que dans trois jours.

Citation:

Envoyé par Chavadam

Merci pour ta double réponse. Surtout celle sur la 'réflexion' ouvre mon horizon.

La réflexion n'est pas la solution la plus optimisée en terme de temps de réponse. L'accès direct aux variables

Concernant C'était pour moi un éclair de solution alternative, cherchant à éviter

Citation:

Envoyé par Chavadam

soit de multiplier les imports d'autres classes, celle contenant 'getNbreCol()' (pour trouver le 'nbreCol'),

La multiplication des imports n'a pas d'importance sur l'exécution, en revanche la réfléxion, si tant est qu'on pourrait l'utiliser pour faire ce que tu veux en a une.

Si une classe a besoin d'une information, c'est normal qu'elle y est accès, par la classe qui la définit, dont avec l'import correspondant qui est nécessaire le cas échéant.

Citation:

Envoyé par Chavadam

soit les longues désignation de cheminement précédant un 'getNbreCol()'

C'est en général, effectivement, à éviter. Si une classe a besoin d'une information, elle doit y avoir directement accès de préférence.

Citation:

Envoyé par Chavadam

située dans une classe d'une autre branche de la bonne instanciation de 'tab_ÉnergÉlectr_TranchePuiss_2x'.

Je comprends pas trop ce que tu entends par "branche d'instanciation" ?

Citation:

Envoyé par Chavadam

'getParent()' n'existe que rarement dans les API et conduirait aussi à un long cheminement -> Je dois oublier.

De quelle API parles-tu ? Si dans une classe, tu as besoin d'une méthode getToto(), tu l'ajoutes à la classe.

Genre
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 public class Exemple { private final Exemple parent; public Exemple() { this.parent=null; } public Exemple(Exemple parent) { this.parent=parent; } public final Exemple getParent() { return parent; } public final Exemple getRacine() { Exemple racine=this; while(racine.parent!=null) racine = racine.parent; return racine; } }
Si l'information ne doit pas nécessairement dépendre d'une hiérarchie, on peut aussi la fournir directement, ou indirectement (fournir une instance qui a l'information), au constructeur, par setter, injection, décorateur, etc. En particulier si tu as une fabrique qui va affecter cette information.

Après, si tu as beaucoup de classes, et que tu veux pouvoir avoir systématiquement certaines méthodes, variables, etc :

par le modèle, par abstraction, interface... (c'est ce que fait Swing, par exemple (javax.swing.JComponent), pour la méthode getParent() justement qui doit exister dans tous les composants)
par annotation (utilisée entre autre pour l'injection par exemple), qui te permettra d'ajouter systématiquement des parties de code, en écrivant un minimum de code
ou éventuellement par aspect (peut-être un peu trop overkill pour ton cas)

28/07/2021, 16h40
Chavadam

Salut Joël.

Ton importante parenthèse :

Citation:

(c'est ce que fait Swing, par exemple (javax.swing.JComponent), pour la méthode getParent() justement qui doit exister dans tous les composant)

° Soit que mon application Swing comporte de nombreuses JFrames, JPane, JPanel, JScrollPane, JTabbedPane suivant une arborescence séparant bien toutes les tables (table_MachChoisies, tablePrinc_TtesCombMach, ...), telle que la description dans ma première intervention n'en montre qu'une partie.
° Soit que le panneau commun où se séparent les codages propres aux panneaux de deux tables est 'tab_ÉnergÉlectr_TranchePuiss_2x' (de classe propre 'ÉnergÉlectrParTranchePuiss' - voir première intervention - pas forcément jusqu'au tronc de l'arborescence)
° Soit que j'ai besoin dans une branche (tabPan_TtesCombMach) de trouver entre autres le 'nbreRangées' ('getRowCount()) de la 'table_MachChoisies' pour pouvoir élaborer dynamiquement la structure de ma 'tablePrinc_TtesCombMach' dans une autre branche,
alors, je pourrais, dans la branche du panneau 'tabPan_TtesCombMach' "remonter" à l'aide de plusieurs 'getparent()' jusqu'au panneau 'tab_ÉnergÉlectr_TranchePuiss_2x', et de là "redescendre" vers le panneau ('.' pour atteindre une propriété ou une méthode) vers le panneau 'table_MachChoisies' pour y pêcher classiquement 'getNbreRangées().
C'était cela, mon inspiration-éclair ... que je testerai quand j'aurai un peu plus de temps pour "jouer".

Ma question était donc quand même à poser dans le forum de Swing ...
Merci bcp.
28/07/2021, 17h12
joel.drigo

Je donnais cette classe de Swing en exemple de classe qui implémente une méthode getParent().

Elle sert à permettre à Swing essentiellement à manipuler la hiérarchie de composants graphiques.

Elle ne sert évidemment pas à permettre au modèle de données d'un composant de connaître les valeurs stockées dans des modèles d'autres composants de la GUI.

Les modèles n'ont pas à savoir qu'ils sont dans des composants graphiques, encore moins y accéder. La communication est faite par le contrôleur (modèle MVC) qui réagit aux changements dans un modèle (le modèle ne fait que signaler qu'il y a un changement).

Les modèles peuvent communiquer éventuellement entre eux, mais surtout pas via les composants d'UI, sauf cas vraiment très particulier (qu'on ne peut pas résoudre autrement à cause de contrainte d'implémentation de Swing). On peut éventuellement refléter une hiérarchie dans un modèle qui encapsule les modèles des composants qui seraient liés dans l'UI.

Par exemple, un arbre (JTree) avec des composants d'affichage du détail des items de l'arbre, dans lequel on voudrait afficher en entête un breadcrump, donc nécessairement accéder à la hiérarchie des nœuds de l'arbre. Le modèle de nœud ne doit surtout pas passer par le JTree pour connaître son parent (surtout qu'il pourrait ne pas être affiché dans un JTree, en l'occurence, dans cet exemple, au moins dans JTree, un JComponent quelconque pour le détail, encore un autre pour le breadcrumb, etc).