Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Design Patterns Discussion :

Hierarchie de classe


Sujet :

Design Patterns

  1. #1
    Invité
    Invité(e)
    Par défaut Hierarchie de classe
    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.
    Dernière modification par Invité ; 26/10/2014 à 15h59.

  2. #2
    Expert éminent
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    juillet 2013
    Messages
    3 012
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 3 012
    Points : 6 691
    Points
    6 691
    Par défaut
    Citation Envoyé par Nouveau2 Voir le message
    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

  3. #3
    Invité
    Invité(e)
    Par défaut
    Salut,

    Citation Envoyé par foetus Voir le message
    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, @+

  4. #4
    Invité
    Invité(e)
    Par défaut
    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 ?

  5. #5
    Invité
    Invité(e)
    Par défaut
    Donc finalement, je me répond à moi-même :

    Citation Envoyé par Nouveau2 Voir le message
    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.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Hierarchie de classe pour Perl/Tk
    Par astrotouf dans le forum Interfaces Graphiques
    Réponses: 4
    Dernier message: 12/11/2007, 10h14
  2. [MFC] Hierarchie des classes MFC
    Par venomelektro dans le forum Visual C++
    Réponses: 2
    Dernier message: 20/03/2007, 16h27
  3. Réponses: 31
    Dernier message: 30/03/2006, 16h57
  4. [Language]Hierarchie de classe unique c'est quoi ?
    Par Le Pharaon dans le forum Langage
    Réponses: 1
    Dernier message: 16/09/2005, 17h58
  5. Pb de hierarchie de classe .
    Par Clad3 dans le forum C++
    Réponses: 14
    Dernier message: 22/01/2005, 12h07

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo