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.