afficher >><< masquer ]
SAMPI - Editeur structuré
1. Le Problème et la Proposition
2. Le Langage Primitif de Représentation Textuelle
2.1. Présentation de la Syntaxe Concrète
2.2. Notations
2.3. Exemple de structuration des données
2.4. Exemple de structuration des traitements
2.5. Exemple de structurations connexes
3. Le Langage Complété pour la Structuration des Textes
3.1. Présentation de la Syntaxe Complétée
3.2. Etude quantitative de l'évolution des programmes
3.3. L'édition syntaxique
3.4. étude de cas : le langage LTR3 et l'atelier ENTREPRISE
4. L'Enrichissement du Langage par de Nouveaux Concepts
4.1. Présentation de la Syntaxe Abstraite
4.2. Les difficultés
4.3. Compléter la Syntaxe
5. La Formalisation des Solutions Techniques
5.1. L'évaluation fonctionnelle
5.2. La structuration par les objets
5.3. Modèle sémantique comparé de l'évaluateur
5.4. Comparaison critique
5.5. Construction de la Syntaxe Abstraite
6. Les Comparaisons avec d'autres Approches
7. Les Perspectives
8. Les Editeurs
8.0. brisé sur la barrière de la complexité (une fois de plus)
8.1. L'éditeur ligne : Manuel de l'utilisateur
8.2. L'éditeur page : Guide de l'utilisateur
9. Les Aspects d'Implantation
9.1. Contexte d'évaluation
9.1.0. Introduction
9.1.1. Modularité
9.1.2. Encapsulation
9.1.3. Paramètre
9.1.4. Emploi par référence
9.1.5. Exemples d'application
9.1.6. Héritage de propriétés
9.1.66.1. Héritage commun
9.1.66.2. Héritage multiple
9.1.66.3. Structuration de l'application
9.1.66.4. Exemple de structure hiérarchique
9.1.7. Polymorphisme
9.1.8. Manipulation symbolique
9.1.9. Le contexte d'évaluation
9.2. La Syntaxe Abstraite : Manuel du concepteur
9.3. L'éditeur page : Guide de l'implanteur
Références
Rubrique Perl-Javascript

Héritage de propriétés

1. Héritage commun

2. Héritage multiple

3. Structuration de l'application

4. Exemple de structure hiérarchique

3. Structuration de l'application

Avec ce qui précède, on a maintenant suffisamment d'éléments pour structurer son application – ou plus exactement le texte source de son application – selon une hiérarchie de textes emboîtés.

On peut immédiatement se demander :

Je n'ai pas de réponse précise à la première question, si ce n'est : employer une Méthode Orientée Objet (MOO) ce qui revient à reporter la question vers la suivante : comment se définit une MOO ?

A ma connaissance, il n'y a pas de réponse formelle, mais plutôt diverses philosophies de programmation dont le point de convergence est justement la construction de programmes orientée par les objets. C'est de l'une de ces philosophies qu'il faudrait s'inspirer pour construire sa hiérarchie.

Quant à la seconde question, je dirai :

On présente un exemple, un peu simple, de situation où même l'emploi d'un langage de « haut niveau » ne permet pas d'éviter la dispersion de notions logiquement liées :

 

On s'intéresse à une boucle :

- initialement, on a : X = A(I)
- dans la boucle : on lit une nouvelle valeur de X
- le test de fin de boucle est : X = A(I+1)

1: 

Le langage impose l'emploi d'une variable comme indice de tableau :
X:=A(I);
I:=I+1;
WHILE X<>A(I) DO Lire(X);

2: 

Le langage, plus évolué, reconnaît un objet du type « A(I+1) » :
X:=A(I);
WHILE X<>A(I+1) DO Lire(X);

3: 

A n'est pas un tableau mais une fonction : on utilise une variable auxiliaire y pour optimiser la recherche :
X:=A(I);
Y:=A(I+1);
WHILE X<>Y DO Lire(X);

4: 

Le compilateur associé au langage possède un bon optimiseur : le bon cas :
X:=A(I);
WHILE X<>A(I+1) DO Lire(X);

5: 

Dans le bon cas : le paramètre de la fonction A est passé par adresse :
X:=A(I);
I:=I+1;
WHILE X<>A(I) DO Lire(X);

6: 

Dans le bon cas : en plus, la fonction A effectue un effet de bord (par exemple : un affichage à l'écran) :
X:=A(I);
I:=I+1;
Y:=A(I);
WHILE X<>Y DO Lire(X);

 

Le cas simple est bien le cas 2. Cependant, diverses contraintes de contexte peuvent conduire à se placer dans le cas 6, et ceci même dans le meilleur des cas – langage évolué, optimisateur puissant.