En développant yLogger, je suis passé par plusieurs versions du programme afin d'éviter quelque chose qui me gène au plus haut point. Je parle de la multiplication des classes.

En effet, WinDev® n'offre pas de notion de package et lorsqu'on déclare une classe, elle est globale à tout le projet. Cela peut devenir rapidement lourd lorsqu'on travaille exclusivement avec la POO et que l'on utilise l'héritage des classes. On peut se retrouver avec un projet ayant énormément de classes qui ne sont utilisées qu'à très peu d'endroit.

Cela fait donc plusieurs années que je cherche des méthodes pour essayer de mettre en place une notion de package pour organiser correctement mes projets. Mais jusqu'à présent, je n'ai rien trouvé qui me convienne...

Mais j'ai quand même découverts des méthodes intéressantes !

Les pseudo-classes

C'est un terme que j'ai inventé dans le cadre de WinDev. J'ai utilisé des structures avec des procédures internes (voir mon article sur les procédures internes.

Cette méthode m'a permis de regrouper au sein d'un même fichier de collection de procédures globales tous les objets dont j'avais besoin. La collection devient ainsi un espace de nom et m'a permis de simuler la notion de package.

De plus, il me suffisait de partager via le gds un seul fichier wdg pour avoir mes pseudos-classes dans n'importe quel projet.

Je pensais avoir trouvé LA solution. Seulement, bien qu'on puisse la simuler un peu, la dérivation des classes n'est hélas pas possible avec cette méthode.

Pire, si j'encapsulais cette collection dans un composant et que je l'utilisais dans un composant, il ne m'était plus possible d'utiliser les procédures internes dans un composant (j'y reviendrai certainement dans un autre article).

Cette méthode est donc très intéressante, mais elle a son lot de défaut. Je l'utilise donc toujours, mais avec parcimonie...

Le composant

En travaillant avec la méthode précédente sur les composants, j'ai vu une fonctionnalité très intéressante qui pouvait peut-être m'aider. J'ai donc ré-écris yLogger en utilisant des classes en lieu et place de mes pseudos-classes.

Je me suis donc retrouvé avec plusieurs classes que je ne souhaitais pas afficher dans mes projets. J'ai donc utilisé cette fonctionnalité qui est d'indiquer les éléments accessibles et j'ai décoché tous ceux que je ne voulais pas voir apparaître à l'exception des classes de base qui me permettent de manipuler les autres.

Ce qui donne ça :
Éléments accessibles

Mais cette technique ne permet pas d'instancier mes classes dérivées. Pour contourner cela, j'ai tout simplement fait ce que je faisais pour les pseudos-classes. J'ai défini dans ma collection de procédure initiale une fonction qui appelle le constructeur de la classe dérivée.

PROCEDURE créer_formateur_json()
formateur est un cFormateur dynamique = allouer un cFormateurJson()
Renvoyer formateur

Et voilà, avec cette méthode, j'ai pu utiliser et instancier une classe sans qu'elle soit accessible (et visible) dans le projet qui utilise les composants. Et tout cela en mettant accessibles 4 fichiers au lieu de 9 dans mon exemple).

Cette méthode n'est pas donc pas parfaite mais si vous travaillez avec des composants et la POO, vous pouvez l'utiliser pour faire un peu de ménage dans votre projet principal (celui qui intègre les composants).

Résumé

Nous avons vu dans cet article deux méthodes pour diminuer le nombre de classes dans un projet. L'utilisation de mon concept de pseudo-classe et l'utilisation d'un composant avec une collection de procédures pour masquer les classes non nécessaires.

Ces méthodes ne sont pas parfaites, mais elles permettent de mieux organiser le code.

Conclusion

Pour le moment, je suis assez satisfait de cette technique. N'hésitez pas à partager les vôtres pour mieux organiser le code et faire un peu de ménage dans l'explorateur de projet.

Je vous remercie d'avoir lu ce billet et j'espère qu'il vous inspirera.

Jonathan Laurent

Read more posts about this author.

Comments