coo poo 1 3 6 6 programmation virtuelle

6.La programmation virtuelle

 

    La programmation virtuelle vient de l'héritage multiple virtuel.

* Dans l'héritage simple un objet fils hérite de son objet parent.

* Dans l'héritage multiple, un objet fils hérite de plusieurs parents.

* Dans l'héritage multiple virtuel, un objet fils hérite de plusieurs parents mais il (l'objet fils) n'est pas explicité c'est à dire l'héritage multiple est déduit mais n'est pas physiquement programmé à l'intérieur de l'objet fils, l'objet fils n'existe pas physiquement dans le système il existe seulement virtuellement et pourtant il existe puisqu'il est visible de l'extérieur à la fin, en fait quand on est à l'extérieur on le voit mais quand on va dedans on ne peut pas le toucher c'est comme un hologramme qui est la conjonction de plusieurs sources de lumière.

* Dans l'héritage à répétion, on fait succéder plusieurs cycles d'héritages et la résultante finale est comme un héritage multiple mais au lieu d'être simultané (comme dans un cycle unique) c'est un cumul de caractéristiques héritées dans le temps.

* On peut combiner l'héritage multiple avec l'héritage à répétition ce qui fait qu'au bout de peu de cycles (héritage à répétition) on hérite de plus de caractéristiques (par héritage multiple à chaque cycle) que si on utilisait l'héritage à répétition seul.

* On peut augmenter la puissance de l'héritage multiple en augmentant le nombre de tables jointes ou la richesse et variété de caractéristiques incluses dans chaque table de paramètres.

 

-------------------

 

    Le module de lecture du folio 1 est capable de faire 11 types de lectures différentes selon les origines mais au niveau haut de l'analyse, on ne s'occupe pas de la question comment il fait les lectures.

    Le polymorphisme donne la puissance de l'analyse

    L'héritage donne la puissance de la programmation.

    Le polymorphisme combiné à l'héritage donne la programmation virtuelle encore plus puissante que le polymorphisme seul ou l'héritage seul.

    Virtuel signifie que chaque ligne sort juste comme la maquette le demande mais ses caractéristiques (de la ligne) ne sont explicitement programmées nulle part (ni pour la ligne, ni pour le groupe de lignes comme "ressources") ni dans l'analyse organique, ni dans la programmation SQL.

    Les caractéristiques d'une ligne sont hérités à travers une série de cycles d'héritages multiples polymorphes (multiple ==> plusieurs tables jointes; polymorphe ==> plusieurs SELECT parallèles en rateau réunies par des UNION). La diversité des lignes ainsi produites est très grande comparée au nombre de modules (4) et de formes (4 en moyenne) nécessaires.

 

4 modules * 4 formes par module = 4 queries * 4 SELECT par query

= 16 select au total

qui génèrent 4 * 4 * 4 * 4 = 256 types de traitements possibles.

Etant donné que chaque SELECT est joint à une table de paramètres qui met en jeu plusieurs lignes par SELECT, cela fait des milliers de variantes de lignes potentiels pour un nombre très limité de queries:

 

    Si on suppose qu'un SELECT est joint à 10 lignes de tables paramètres en moyenne,

 alors 4 queries de POO Virtuelle peuvent traiter 256 * 10 = 2560 types de lignes différentes.


 

    Voilà la puissance de la POO Virtuelle : très peu de queries (4) peuvent traiter une diversité énorme de lignes d'état (2560) à analyse fonctionnelle toutes différentes et complexes à tous les niveaux (origine des données, calculs variés, totalisations à plusieurs niveaux, éditions changeantes).

    Face à une demande fonctionnelle très complexe et hyper instable (maquette élastique), on est capable grâce à la POOV d'écrire une programmation hyper simplifiée, concise et très souple dont les résultats sont rigoureusements conformes à la maquette demandée.

    Même un débutant (sur RTGE) D.A. est capable de coder rapidement et de façon exacte toutes les nombreuses modifications variées demandées par les utilisateurs à la dernière minute.

    La taille du logiciel est devenue presque indépendante du nombre de variances de lignes à sortir car des lignes nouvelles ajoutées ne nécessitent pas l'adjonction de queries ou de tables dans la procédure mais seulement l'ajout ou la modification de lignes dans les tables de paramètres.

    C'est ainsi que lorsqu'on ajoute toutes les lignes des folios 7 et 8 dans le folio 5, cela ne complexifie pas la procédure du folio 5 ou le nombre de tables de paramètres et tables permanentes du folio 5 mais cela ne fait qu'ajouter des lignes en plus dans les tables de paramètres du folio 5.

    De ce constat (les lignes ajoutées n'augmentent pas le nombre de queries, de tables de données et tables de paramètres) on peut déduire que dans le futur les lignes ajoutées ou modifiées ne vont pas non plus faire ajouter des queries ou des tables à la procédure du RTGE. Ce qui n'est pas le cas de l'ancien RTGE (et SICOGE) où le raisonnement dans la programmation est basé sur les lignes d'état. Dans le vieux RTGE (et SICOGE), à chaque type de ligne correspond une procédure. Donc plus il y a de types de lignes d'état, plus la procédure s'allonge, la taille et la complexité de la procédure est proportionnelle au nombre de types de lignes de l'état.

 

    Dans le nouveau RTGE on raisonne par domaines: il existe 4 domaines (lecture,calcul,totaux,mise en forme), on traite les domaines un à un. Chaque domaine contient des types. Chaque type détermine une classe. Une classe contient des lignes de même type. On programme un domaine en entier (par une query) en programmant de façon parallèle (par des SELECT) toutes ses classes. Une fois que le domaine est programmé toutes les classes du domaine sont programmées et toutes les lignes des classes sont programmées concernant ce domaine (par exemple: lorsque la tâche de lecture est exécutée, toutes les lignes sont lues). Par cette méthode (exécution de tâches successives chaque tâche réglant un domaine) au bout de 4 tâches, toutes les lignes sont traitées sans que l'ajout ultérieur de variances de lignes n'ajoute au nombre de tâches. C'est celà qui permet de réduire au minimum le nombre de queries et de tables intermédiaires dans l'application RTGE 96.