Windev et POO (variant?)
PERCAPITA
pas encore testé en 7)
MonObjet est un objet dynamique //Et hop on ne spécifie pas la classe
MonObjet peut recevoir maintenant une instance de n'importe qu'elle classe
(un peu comme le type variant dans d'autre language plus typé)
PERCAPITA
Un peut allouer un objet dynamique avec n'importe quoi ! Le compilateur ne
bronche pas !
Exemple
MonObjet est un objet MaClasse1 dynamique
MonObjet = allouer un MaClasse2 //Ca passe, bonjour les bugs
"PERCAPITA" <PERC...@WANADOO.fr> a écrit dans le message de news:
b257sb$2sf$1...@news-reader10.wanadoo.fr...
Fabriceburg
>J'ai trouvé le moyen de déclaré un objet de type "variant" dans windev (5.5
>pas encore testé en 7)
:-/
en 7 il y a un type variant mais j'sais pas ce qu'il vaut...
Fabrice Burghgraeve
(enlever le -spamout pour me repondre en prive)
Pierre-Yves Tavernier
toutes les classes.
En effet si cette classe s'appelle ObjetMaman.
Et que toutes les classes hérite de ObjetMaman, alors on peut définir un
objet de type ObjetMaman et lui affecter n'importe quel objet héritant de
ObjetMaman.
C'est il me semble le mécanisme de PolyMorphisme.
Et c'est l'un des principes qui rend la POO trés puissante.
Par exemple
soit une classe Avion
implémentant les services decoler, atterir, voler, atterir, faire_le_plein,
comminiquer_avec_la_tour de_controle.
Tous les 747, sesna (je sais pas si ca s'ecrit comme cela) hériteront de la
classe avion et hériteront donc des services de la classe avion, mais
implémenteront leur manière personnel de remplir leurs services.
Ainsi si on possede une collection d'avions (un de mes rêves d'enfants :) )
on pourra de la meme façon faitre decoler un sesna, un 747, .... par des
mécanismes du type
MacollectionDavion[Mon747].decolle;
MaCollectionDAvion[UnSesna].decolle.
Ainsi on peut facilement ajouter d'autres types d'avions sans devoir revoir
tous les decollage et les atterissage.
Pour la création des avions on pourra utiliser une usine à objet
(ObjectFactory).
Le type Variant a été il me semble créé pour communiquer avec les ActiveX et
n'a rien à voir avec de la POO.
PYT
"PERCAPITA" <PERC...@WANADOO.fr> a écrit dans le message news:
b257sb$2sf$1...@news-reader10.wanadoo.fr...
> J'ai trouvé le moyen de déclaré un objet de type "variant" dans windev
(5.5
> pas encore testé en 7)
>
> MonObjet est un objet dynamique file://Et hop on ne spécifie pas la classe
Nicole Chanal
truc qui marchait bien en Windev 5 et qui ne marche plus dans la
version 7: si je reprends l'exemple des avions, supposons que le sesna
sache faire une action qui lui est propre. On définit une méthode dans
la classe sesna qui n'existe pas dans la classe parent. Et bien, si
l'on écrit une ligne du type MaCollectionDAvion[UnSesna].
laMethodeDuSesna(), ça passera bien à la compilation mais on obtiendra
une erreur à l'exécution avec Windev 7.
Mon astuce pour éviter le problème (évoquée dans un post sur la classe
Collection de D.Baussy) a été de créer une méthode virtuelle renvoieMoi
dans chaque classe concernée. Le code de cette méthode:
FONCTION virtuelle renvoieMoi()
renvoyer objet
Il faut remplacer la ligne qui plante par:
MaCollectionDAvion[unSesna].renvoieMoi().laMethodeDuSesna()
c'est lourd mais ça marche.
--- Message d'origine ---
mécanismes du type
PYT
--
Article posté depuis le site FORUMS WINDEV® :
http://windev.wdscript.com
Une archive de plus de 90000 articles sur Windev® et Webdev®
--
Yannick Simon
normal. Par définition, une collection est un ensemble d'objets qui peuvent
être différents, généralement implémentée par une liste. Donc pointer
l'objet voulu dans la liste, le lire, puis l'utiliser (appels à ces
méthodes) me semble très logique.
Pour en venir aux problèmes d'erreurs:
Supposons que nous ayons 3 classes
- une classe générique TCollection avec une méthode getCourant (renvoie
l'objet en cours dans la collection)
- une classe TAvion avec une méthode décoller
- une classe TChaussette avec une méthode raccommoder()
Nous implémentons une collection d'avions. (MaCollectionDAvion est un objet
TCollection et ne contient que des avions)
si j'écris:
MaChaussette est un objet dynamique
MaChaussette = MaCollectionDAvion:getCourant()
MaChaussette:raccommoder()
Dans ce cas, MaChaussette est un avion, impossible de le raccommoder.
L'erreur (Raccommoder n'est pas une méthode de l'objet TAvion) surviendra à
l'éxécution.
Par contre, si j'écris:
MaChaussette est un TChaussette
MaChaussette = MaCollectionDAvion:getCourant()
MaChaussette:raccommoder()
L'erreur surviendra à la compilation (MaChaussette n'est pas un avion, type
d'objet que renvoie MACollectionDAvion)...d'où l'interêt de typer ses
objets.
Euh, je ne suis pas sur d'avoir été très clair...enfin, vous aurez compris
que je travaille pour la chaussette ;-)
Romuald Besset
cette possibilité.
1/ les classes 'généralistes' qui peuvente être utilisées dans d'autres
projets.
2/ les classes 'projet' qui apportent plutot une simplification du code
des fenêtres (toujours mieux que des procédures globales
les premières sont instancié en déclaration de projet
les seconde, dans les modules où elles sont utilisée.
Là ou on a un truc pas mal, c'est justement le transfert d'instances
grâce au passag de paramètres par adresse (par défaut).
Prenons le cas d'une classe de gestion des Log (enregistrement des
infos lors de l'execution de l'appli, dispo sur rbesset.net), il s'agit
d'une classe généraliste.
Aussi, une classe commande est spécifique à notre projet. ses méthodes
d'écritures dans la base doivent faire appel au méthodes de l'objet de
log.
pour résoudre cela, on a modifie la classe COMMANDE comme suit :
// niveau projet (globales)
goLog est un cLog
////////////////////////////
Déclaration de COMMANDE
oLog est un objet dynamique
constructeur de COMMANDE
Constructeur(poLog)
:oLog=poLog
destructeur()
// RAF, on ne libère par l'objet défini en globale au projet !!!
////////////////////////////////
// Utilisation :
// niveau projet (globales)
goLog est un cLog
// dans le module
ocommande est un COMMANDE (golog) // l'instance est passée par adresse !!
!
NB : le passage par adresse ici, nous permet d'utiliser LA MEME
instantce dans les classes projet que dans le projet lui même ce qui
est tres interessant pour la gestion des membres de l'objet
'généraliste' et certaines fonctionnalités commes des triggers... sans
compter qu'on ne surcharge pas la mémoire !
@+ R&B de rbesset.net : portail windev
--- Message d'origine ---
mécanismes du type
PYT
--
PYT
>C'est effectivement une des forces de la POO. Par contre, il y a un
>truc qui marchait bien en Windev 5 et qui ne marche plus dans la
>version 7: si je reprends l'exemple des avions, supposons que le sesna
>sache faire une action qui lui est propre. On définit une méthode dans
>la classe sesna qui n'existe pas dans la classe parent. Et bien, si
>l'on écrit une ligne du type MaCollectionDAvion[UnSesna].
>laMethodeDuSesna(), ça passera bien à la compilation mais on obtiendra
>une erreur à l'exécution avec Windev 7.
>Mon astuce pour éviter le problème (évoquée dans un post sur la classe
>Collection de D.Baussy) a été de créer une méthode virtuelle renvoieMoi
>dans chaque classe concernée. Le code de cette méthode:
>FONCTION virtuelle renvoieMoi()
>renvoyer objet
>Il faut remplacer la ligne qui plante par:
>MaCollectionDAvion[unSesna].renvoieMoi().laMethodeDuSesna()
>c'est lourd mais ça marche.
J'en comclue que la liaison dynamique ne fonctione pas en Windev 7. PC SOft a t-
il prévu en correctif. Sinon la POO perd de son interet et de sa force avec
Windev.
PYT
--
Ce message a été posté via la plateforme Web club-Internet.fr
This message has been posted by the Web platform club-Internet.fr