 |
Vendredi 06 juin 2025 - 12:20 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Lisez attentivement ce qui va suivre car la notion de POO (pour Programmation Orientée Objet) est non seulement à la pointe du développement informatique mais de plus, elle entre en force sur notre machine préférée. Citons trois produits qui utilisent actuellement cette notion de POO : UIK (User Interface Kit), le C++ et... le système 3.0 ! Le système 3.0 ? La datatypes.library exploite en effet les atouts de la POO. Merci monsieur Commodore...
Origines de la POO
Au départ, il y a bien entendu le langage C. Celui-ci reste un outil de développement très puissant permettant de manipuler à la fois des concepts de haut et de bas niveaux (Cf. assembleur). Mais il ne suffit pas de pouvoir bénéficier d'un langage de haut niveau pour résoudre d'un coup de baguette magique les problèmes rencontrés par le génie informatique. Restent en effet les éternels problèmes de maintenance et de réutilisation des applications.
Pour bien comprendre, vous devez vous rendre compte que plus un programme est modulaire et indépendant des données qu'il utilise, plus sa maintenance par exemple en sera facilitée. La modularité ne peut pas non plus tout résoudre car chaque module d'un programme C ne peut communiquer avec un autre qu'au travers d'une interface externe réduite, l'intérieur de ces modules restant une sorte de boîte noire inviolable par les autres modules... On parle alors de phénomène d'encapsulation (limitation d'accès à l'information).
Lorsque vous écrivez deux programmes, utilisant une interface graphique de haut niveau, il vous faudra certainement revoir vos routines d'affichage de menus (par exemple) qui devront être parfaitement adaptées à chaque application. Le morceau de choix de la programmation objet se base sur une nouvelle nécessité qui est la réutilisation des modules/données. En effet, l'analyse de l'évolution des logiciels a montré, qu'en général, les éléments les plus stables étaient les structures de données et que les modifications portaient essentiellement sur les fonctions de manipulations de ces informations.
Cette analyse a conduit à l'idée de centraliser les données en leur associant les traitements spécifiques qui les manipulent plutôt que de centrer les programmes sur les fonctions, traitements qui sont susceptibles d'être modifiées plus fréquemment. Il s'agit du concept de base, fondamental, de la POO : associer les traitements aux données.
Objectifs de la POO
Rendre l'application portable
C'est la possibilité d'utiliser le programme source sur d'autres machines ou environnements différents. La POO permet d'isoler les détails d'implémentation aux niveaux les plus bas, c'est-à-dire lors de la spécificité des objets eux-mêmes. Donc pour rendre une application portable en POO, il suffit de redéfinir les données décrites des objets utilisés (Cf. datatypes.library Kickstart 39).
La compatibilité
Mon application doit s'intégrer dans l'environnement existant. C'est-à-dire qu'il ne suffit pas qu'elle fonctionne correctement. Elle ne doit pas empêcher le déroulement normal d'autres tâches en cours. Bref, elle doit respecter le multitâche (Cf. UIK).
La vérifiabilité
C'est sous ce terme que l'on désigne la manière plus ou moins aisée de définir des procédures testant les logiciels. La modularité de la POO permet une vérification plus aisée, élément par élément.
La réutilisabilité
Pour pouvoir réutiliser des modules développés pour une autre application, il faut fournir un effort dès la conception afin de produire des modules "paramétrables". Ces modules doivent faire face à toutes les situations que l'on pourrait rencontrer ultérieurement. L'emploi de l'héritage (Cf. plus loin) en POO apparaît comme une solution très encourageante.
L'extensibilité
C'est la faculté de pouvoir ajouter des données ou/et modules supplémentaires sans endommager le logiciel existant. Les notions de limitation d'accès et d'héritage y répondent partiellement.
On ne peut pas tout avoir... Par exemple, un programme efficace (tenant compte de toutes les possibilités de la machine) sera très difficilement portable... Car un programme portable se cantonne à formuler un concept de manière standard et est donc bien souvent peu performant. Dans l'ensemble, la POO donne plus de réponses au "génie informatique" que la programmation dite classique.
Notion de classe
Définition : "Entité qui définit de manière générale la structure, les propriétés et les opérations d'éléments de données manipulés par le logiciel". A la base de la notion de classe se trouve le concept de type abstrait... Pour ne pas rentrer dans trop de détails techniques voici un exemple de type abstrait :
La structure rectangle contient une entrée de type "float" qui sera donnée comme étant la valeur retour de type "float" de la fonction "perimetre" ! On associe aux données les fonctions qui les manipulent ! En POO les éléments constituant la structure sont appelés des membres. Une fonction membre est appelée méthode.
La déclaration de la fonction se fait à l'intérieur même de la structure définissant le type abstrait. Il est tout à fait concevable de se contenter de définir le prototype de la fonction seulement (la fonction est alors définie plus loin dans le source).
La structure "rectangle" est une classe. "rect" est un objet. Pour appeler la fonction "perimetre" il faut utiliser l'instruction "rect.perimetre()" pour envoyer le message "perimetre" à l'objet "rect" de classe "rectangle", ce qui provoque l'appel de la méthode "perimetre()".
L'héritage
Le principe de l'héritage est de décrire un nouveau type abstrait non pas à partir de rien mais par extraction d'un type (ou plusieurs) déjà existant. Hériter d'une classe consiste à recevoir toutes les caractéristiques de cette classe et à y adjoindre des éléments supplémentaires.
En gros, lorsqu'une classe X hérite d'une classe Y, la classe héritière est riche de toutes les fonctions offertes par la classe parente (ou mère) Y. En ce qui concerne les données, la classe fille possède toutes les données de la classe mère. En d'autres termes, la classe héritière possède tous les membres (données et fonctions) de la classe mère. Les nouveaux membres hérités peuvent aussi être redéfinis et on obtient alors la notion d'héritage en cascade...
UIK
UIK est l'abréviation de User Interface Kit, et a été créé par Jean-Michel Forgeas. Il s'agit d'une bibliothèque système qui reprend le concept général de la POO. UIK est livré avec un manuel de 88 pages d'aspect assez technique. Je pense que même si évidemment UIK peut être utilisé avec n'importe quel langage compilé, il est préférable d'avoir une solide connaissance en C avant de se plonger tête baissée dans le manuel... Dès le départ l'auteur nous parle d'objet et si vous n'avez aucune notion de POO cela risque de vous paraître assez étrange à première vue.
UIK fonctionne sur n'importe quel Amiga et sous n'importe quel Kickstart. L'uik.library vous privera d'un volume de 60 ko dans votre Libs:.
Objet UIK
Le noeud (root) de base est l'objet UIK. A partir de celui-ci, on construit en cascade d'autres objets. La notion d'héritage est ici une réalité : si on supprime un parent tous ses fils seront également supprimés.
Les objets sont de deux types. Les objets internes et les objets externes. Un objet interne est disponible dès l'ouverture de l'uik.library. Un objet externe se trouve dans un répertoire (UIK:Objects), UIK devant le charger en mémoire avant exécution. Une documentation complète est disponible décrivant les objets internes et externes. Les étapes de base d'un programme utilisant uik.library sont :
- 1. Ouvrir l'uik.library.
- 2. Ajouter les objets.
- 3. Ajouter un événement à attendre.
- 4. Activer les objets.
- 5. Attendre un événement utilisateur.
- 6. Désactiver les objets.
- 7. Fermer l'uik.library.
Ouvrir l'uik.library
Rien de très sorcier :
Ajout d'objets
L'ajout d'un objet ne signifie pas son activation. Cela revient à une déclaration de l'objet. On ajoute un objet en le reliant à son parent. L'objet primaire (root) UIK ne possède pas de parents. C'est un objet spécial qui porte le nom de "graine" : tous les autres objets sont construits à partir de celui-ci.
Ajout d'événements
A chaque objet on peut associer un événement (ou plusieurs). Ce couple objet/événement est appelé vecteur. Si l'événement se produit, UIK exécute la fonction qui lui correspond en lui transmettant des paramètres. UIK prend en charge la gestion d'attente d'événements, étant toujours prêt à recevoir un événement utilisateur.
Activer les objets
Si un objet parent est activé, il activera en cascade ses fils. Donc l'écriture :
Un nom d'objet seul peut-être spécifié mais si cet objet possède des enfants, ils seront activés à leur tour.
Attendre un événement utilisateur
Attention, on peut également envisager le schéma suivant : nous ouvrons une fenêtre avec un gadget. L'activation du gadget nous branche sur action1() qui est une fonction utilisateur. action1() recherche un pointeur sur sa propre tâche et envoie le signal "Ctrl_C", résultat : le programme se saborde lui-même...
Désactiver les objets et fermer la bibliothèque
Ceci est réalisé très simplement, il suffit de désactiver l'objet de base, c'est-à-dire la graine UIK. Tous les objets y étant reliés (ils sont tous des enfants), ils seront ainsi désactivés.
Exemple concret
Je n'ai eu de problème particulier à utiliser DICE. Bien entendu, aucun problème avec le SAS C car c'est le compilateur qu'utilise Jean-Michel Forgeas.
UIKShow utilise trois objets externes : OBJILBM, OBJSelectFile et OBJjoystick. Dommage que l'objet MOUSEJOY soit en cours de développement car il aurait pu servir dans cet exemple. La uik.library est librement distribuable (ainsi que les objets). Vous pouvez donc vous la procurez dans le domaine public (mais si vous ne la trouvez pas, allez voir dans le Petit Amiga Illustré du mois de janvier 1993, elle s'y trouve).
Conclusion
En ne prenant pas en compte la période d'adaptation au logiciel, j'ai programmé UIKShow très rapidement, ceci grâce à la programmation objet et surtout aux objets existants déjà ! Il manque à UIK un peu de finition globale et quelques objets supplémentaires mais dans l'ensemble, je pense qu'UIK répond à ce que l'on attend de lui. La POO ne résout pas tous les problèmes du génie informatique mais réduit le temps de développement. Que demander de plus ? C'est un véritable plaisir de programmer (correctement) avec UIK. Pour moi, il s'agit de l'utilitaire d'aide à la programmation de l'année...
|
Nom : User Interface Kit 1.1. Développeur : Jean-Michel Forgeas. Genre : programmation. Date : 1992. Configuration minimale : Amiga OCS, 68000, 512 ko de mémoire. Licence : commercial. Prix : 550 FF. |
|
