Discussion :

[Invité]

Bonjour a tous,

Débutant dans la Programmation, quelque chose me turlupine depuis quelque temps.
J'ai commencé la programmation avec VBA (Visual Basic pour Application) sous Excel et sous Excel, les classes utilisent une hiérarchie sous la forme:

Application : Une instance Excel.exe de l'application entière instanciable.
...Workbook : Une instance d'un classeur.
......Worksheet : Une instance d'une feuille de calcul.
.........ListObject : Une instance d'un tableau.
............Range : Une instance d'une plage de cellule.

Ici, la relation entre les objets n'est pas lié par l'héritage.(?)
Application n'a potentiellement rien à voir avec Workbook (il n'y a pas de point commun), pourtant, à chaque fois que je fais des recherche sur des hiérarchies dans les applications, je retombe souvent sur la notion d'héritage.

Pour expliquer un peu:
Ici, la classe Application contient une propriété en lecture seule appelée "Workbooks" qui renvoie une instance de classe de type collection Workbooks. Réciproquement, la classe Workbooks renvoie une Instance de son Parent qui est Application.
Cette classe Workbooks possède des Méthodes typique de classe de type Collection tel que Add, Item, Delete, _NewEnum (pour itérer) ...
La propriété Item renvoie justement un Object de type compatible avec Workbook (qui est en fait un objet dérivée de Workbook), tandis que .Add fabrique un sous-type de Workbook.

Et ainsi de suite, on peut voyager du sommet de la hiérarchie du modèle objet d'Excel en commençant de Application, puis en finissant par Range (ce n'est qu'un chemin parmi beaucoup d'autre) ou inversement, si on part d'un Range et que l'on veut remonter.

Question:
Quel est la manière la plus propre pour fabriquer ce genre de hiérarchie, parce que j'ai déjà fabriqué de tel hiérarchie (en plus petite) et il me manque quelque chose.
Il faudrait que par exemple dans notre cas, la classe Workbooks puisse avoir des privilèges sur la classe Application pour que Application lui refile automatiquement son Instance de classe et que vise-versa, Workbooks fournisse son Instance à Application sans que les autres classes soient au courant de quoi que soit.
Idem entre Workbooks et Workbook parce que Workbook devrai pouvoir utiliser des propriété en lecture seulement, mais la classe Workbooks devrai pouvoir transmettre les valeurs des propriétés Get sans que la classe Workbook expose une propriété Let/Set publiquement.

J'utilise des Classes Abstaite en VBA avec des propriétés Set/Let pour transmettre les infos, parce que les propriétés implémentés au sein d'une classe sont privées (Genre pour l'exemple : IWorkbookSetProperty avec uniquement des propriétés Set et Let pour permettre une communication privée entre instance classe Object (Workbook) et Collection (Workbooks) pour l'exemple).

Question:
Quel est la voie officielle pour transmettre des Valeurs entre classe (tout en maintenant des propriétés Set privées) sans que les autres classes puisse être au courant de tel transfert d'informations ?

Question:
Comment s'appelle ces genres de design patterns ?
Pattern qui permettent de conserver des Propriété Get en lecture seule sans exposer de propriété Set/Let public tout en permettant l'échange d'infos entre Objet/Collection et Parent/Enfant.

Question:
L'héritage n'est pas obligatoire pour créer des hiérarchies de classe dans les grandes applications ?
Bien qu'ici, dans le cas d'Excel, les feuilles de calcul sont fortement typées (type Feuil1, Feuil2 ...) et dérivent de Worksheet, donc, la collection fabrique des objets dérivées qui hérite de Worksheet, donc il y a de l'héritage, mais c'est sur 1 niveau seulement.

Le but serait d'utiliser une méthode de conception avancée (autre que comme en VBA) pour pouvoir créer des hiérarchies dans d'autres languages tel que le Visual Basic en utilisant des mécanismes de la POO (design pattern).


En espérant ne pas avoir été trop long
Merci d'avance.