PL/SQL local subprograms

[yasstunisien]

bonjour,

pouvez vous m'aider à comprendre l'utilité d'utiliser des "local subprograms"?

c'est à dire comme cet exemple :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
CREATE OR REPLACE PROCEDURE Xyz_P1 IS
 
   FUNCTION xyz_f1(p_i IN NUMBER) IS
   BEGIN
        INSERT INTO libelle VALUES (p_i );
   END;
 
      PROCEDURE xyz_f2(p_j IN NUMBER) IS
   BEGIN
     INSERT INTO libelle VALUES (p_j );
   END;
 
   v_k NUMBER := 6;
   BEGIN
 
   INSERT INTO libelle VALUES (v_k);
   xyz_f1(1);
      xyz_f2(3);
 
	 END;
/

d'autres part j'aime bien comprendre les avantages et les inconvénients de l'utilisation des local subprogram, package.

Merci.

[al1_24]

Dans l'exemple présenté, l'emploi de sous-programmes locaux n'a pas réellement d'intérêt...
Dans la réalité d'un développement, on utilisera un sous-programme local pour factoriser une opération, c'est à dire écrire une seule fois une portion de code qui sera utilisée à plusieurs endroits du programme.
Cela n'est pas propre à PL/SQL mais relève des bonnes pratiques de programmation à mettre en oeuvre quel que soit le langage utilisé, s'il le permet.

[mnitu]

Steven Feuerstein a écrit récemment sur ce sujet dans "Write Tiny Little Chunks of Code - or Maybe Not"

[Cincinnatus]

Envoyé par al1_24

Dans la réalité d'un développement, on utilisera un sous-programme local pour factoriser une opération, c'est à dire écrire une seule fois une portion de code qui sera utilisée à plusieurs endroits du programme.

Les sous-programmes peuvent être utiles aussi pour améliorer la lisibilité du code, en réalisant une opération métier ou technique par sous-programmes. Ensuite, un appel de sous-programmes du type

fonction1
fonction2
fonction3

où les fonctions (ou proc) auront un nom parlant sera plus lisible que

boucle 1
différentes opérations
....
...
fin boucle 1
si cond alors
...
...
fin si
bla
bla
bla

La granularité ne doit pas être la ligne d'instruction mais l'unité logique.


Un autre avantage des sous-programmes privés est d'utiliser les sous-programmes publics comme garde (contrôle de cohérence, des paramètres) et d'avoir les sous-programmes privés plus propres, sans ces contrôles, et centrés sur les opérations à effectuer.

Dans certains langages (pas en PL/SQL), ça peut aussi servir à gérer les accès concurrents dans l'API publique (cf [url]http://www1.cse.wustl.edu/~schmidt/POSA/POSA2/[url]).