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.

[foetus]

Ici, la relation entre les objets n'est pas lié par l'héritage.(?)

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.

Il y a 2 types de hiérarchies (*): la composition/ agrégation et l'héritage.
La différence est la composition/ agrégation est une relation "Has a" (un classeur a 1 ou plusieurs feuilles de calcul) et l'héritage une relation "Is a" (Un carré et un triangle sont des formes).

L'héritage est une relation forte.
Et les interfaces ce sont des "contrats" de ce que doivent faire un objet.

Maintenant recherche sur les Internets parce qu'il a beaucoup de lecture sur ce sujet


Pour ton problème cela me semble tordu
Donc tu veux que l'objet A accède à une partie de B mais pas l'objet C.

En C++, il y a la fameuse notion d'amitié (Internet )

Je vois un truc comme cela, mais c'est assez

1. Tu crées une classe Private_Data, et tu mets un pointeur faible dans la classe A. Un pointeur faible cela veut dire que c'est l'objet B qui est le propriétaire et il donne une référence à l'objet A
2. Pour contraindre, tu peux faire une méthode dans l'objet B pour passer cet objet Private_Data seulement aux objets de type A et non pas de type C.
3. Avec un patron de conception Observer, à chaque fois que l'objet A va modifier l'objet Private_Data, l'objet B sera prévenu.

* -> Peut-être qu'il en a d'autres, merci de ne pas me bananer

[Invité]

Salut,

Il y a 2 types de hiérarchies (*): la composition/ agrégation et l'héritage.
La différence est la composition/ agrégation est une relation "Has a" (un classeur a 1 ou plusieurs feuilles de calcul) et l'héritage une relation "Is a" (Un carré et un triangle sont des formes).

L'héritage est une relation forte.
Et les interfaces ce sont des "contrats" de ce que doivent faire un objet.

Maintenant recherche sur les Internets parce qu'il a beaucoup de lecture sur ce sujet

OK, je ne savais pas que les hiérarchies pouvaient être de 2 types distincts et différents.

Pour la Composition/Agrégation, j'ai lu ça vite fait il n'y a pas longtemps, sans vraiment comprendre d'ailleurs , à la base, c'était pour comprendre un peu mieux les schéma UML.
Merci, je regarderai ça de plus prêt notamment ici pour la composition/agrégation/association: http://bellekens.com/2010/12/20/uml-...s-association/

Pour ton problème cela me semble tordu
Donc tu veux que l'objet A accède à une partie de B mais pas l'objet C.

En C++, il y a la fameuse notion d'amitié (Internet )

Je vois un truc comme cela, mais c'est assez

1. Tu crées une classe Private_Data, et tu mets un pointeur faible dans la classe A. Un pointeur faible cela veut dire que c'est l'objet B qui est le propriétaire et il donne une référence à l'objet A
2. Pour contraindre, tu peux faire une méthode dans l'objet B pour passer cet objet Private_Data seulement aux objets de type A et non pas de type C.
3. Avec un patron de conception Observer, à chaque fois que l'objet A va modifier l'objet Private_Data, l'objet B sera prévenu.

* -> Peut-être qu'il en a d'autres, merci de ne pas me bananer

En C++, il y a la fameuse notion d'amitié (Internet )

C'est, je pense, exactement ça. Je n'ai pas voulu employer le mot Friend car ce mot clé veut dire "Interne au Project" en Visual Basic, mais je pensais justement à un genre de Modificateur qui permettent de sélectionner des classes "amis" qui aient le droit de communiquer avec elle et pas avec d'autres classes. Mais ça n'existe pas dans VB ou même sauf erreur en C#.
J'aurai aimé que par exemple dans une relation Object/Collection, une classe Collection Cs1 puisse être la seule à pouvoir instancier une classe Object C1 (c'est un exemple, mais idem pour la relation Parent/Enfant) dans le même Assembly/Project.

Pour les pointeurs par contre, ça ne sera pas possible car trop compliqué à mettre en oeuvre en .NET.
En tout cas merci , je vais considéré que c'est résolu, je verrait au fil du temps comment ça se passe la POO. J'ai encore beaucoup à apprendre.

Merci, @+

[Invité]

Salut,


Incroyable

Je viens de voir que la technique que j'utilise est une technique connu sous le nom de dépendence d'injection ou d'Interface injection !

Source : Dependency injection

C'est donc la preuve que finalement, mon code avec l'interface IxxxxxxSetProperty (où xxxx est le nom de la classe qui implémente l'interface) n'est pas bête du tout !!!


Par curiosité, est-ce que cette technique est connu et est conseillé tout de même ?

[Invité]

Donc finalement, je me répond à moi-même :

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.

Ce genre de pattern, c'est l'injection de dépendance sous la forme d'une Injection par interface tout simplement .


P.S.: En VBA, les Interfaces personnalisées n'existant pas, il faut utiliser des classes Abstraitres.