Petit Manuel de S4

Le plus simple est de prendre un exemple et de comparer la programmation classique à la programmation objet. L'IMC, l'Indice de Masse Corporelle est une mesure de maigreur ou d'obésité. On le calcule en divisant le poids (en kilo) par la taille au carré. Ensuite, on conclut :

• 20 < IMC < 25 : tout roule pour vous ;
• 25 < IMC < 30 : Nounours ;
• 30 < IMC < 40 : Nounours confortable ;
• 40 < IMC : Méga nounours, avec effet double douceur, mais qui devrait tout de même aller voir un médecin très vite…

• 18 < IMC < 20 : Barbie ;
• 16 < IMC < 18 : Barbie mannequin ;
• IMC < 16 : Barbie squelette, même diagnostic que le Méga nounours, attention danger…

On veut donc calculer l'IMC. En programmation classique, rien de plus simple :

> ### Programmation classique, IMC
> poids <- 85
> taille <- 1.84
> (IMC <- poids / taille^2)

[1] 25.10633

Jusque là, rien de très mystérieux. Si vous voulez calculer pour deux personnes Moi et Elle, vous aurez :

> ### Programmation classique, mon IMC
> poidsMoi <- 85
> tailleMoi <- 1.84
> (IMCmoi <- poidsMoi / tailleMoi^2)

[1] 25.10633

> ### Programmation classique, son IMC
> poidsElle <- 62
> tailleElle <- 1.60
> (IMCelle <- poidsMoi / tailleElle^2)

[1] 33.20312

Ça marche… sauf qu'Elle est qualifiée de « Nounours confortable » (ou « Nounoursette » dans son cas) alors que son poids ne paraît pas spécialement excessif. Un petit coup d'œil au code révèle assez vite une erreur : le calcul de IMCelle est faux, nous avons divisé poidsMoi par tailleElle au lieu de poidsElle par tailleElle. Naturellement, R n'a pas détecté d'erreur : de son point de vue, il a juste effectué une division entre deux numeric.

En langage objet, la démarche est toute autre. Il faut commencer par définir un objet IMC qui contiendra deux valeurs, poids et taille. Ensuite, il faut définir la fonction print qui affichera l'IMC(2) :

> ### Définition d'un objet IMC
> setClass("IMC", representation(poids ="numeric", taille ="numeric"))

[1]  "IMC"

> setMethod("show", "IMC",
+     function(object) {
+         cat("IMC =", object@poids /(object@taille^2) , "\n")
+     }
+ )

[1] "show"

Le code équivalent à ce qui a été fait dans la section I.A.3.aProgrammation classique est alors :

> ### Création d'un objet pour moi, et affichage de mon IMC
> (monIMC <- new("IMC", poids =85, taille =1.84))

IMC = 25.10633

> ### Création d'un objet pour elle, et affichage de son IMC
> (sonIMC <- new("IMC",poids =62, taille =1.60))

IMC = 24.21875

À partir du moment où l'initialisation est correcte (problème qui se posait également dans la programmation classique), il n'y a plus d'erreur possible. Là est toute la force de l'objet : la conception même du programme interdit un certain nombre de bogues.

Typage : l'objet protège également des erreurs de typage, c'est-à-dire les erreurs qui consistent à utiliser un type là où il faudrait en utiliser un autre. Une erreur de typage, c'est un peu comme additionner des pommes et des kilomètres au lieu d'additionner des pommes et des pommes.

Concrètement, une variable nommée poids est conçue pour contenir un poids, c'est-à-dire un nombre et non une chaîne de caractères. En programmation classique (pas de typage), poids peut contenir n'importe quoi :

> ### Programmation classique, pas de typage
> (poids <- "Bonjour")

[1]  "Bonjour"

En programmation objet, affecter "bonjour" à une variable qui devrait contenir un nombre provoquera une erreur :

> new("IMC", poids ="Bonjour", taille =1.84)

Error in validObject(.Object) :
   invalid class "IMC" object :
invalid object for slot "poids" in class "IMC": got class
"character", should be or extend class "numeric"

Vérificateurs : l'objet permet de construire des vérificateurs de cohérence pour, par exemple, interdire certaines interdire certaines valeurs. En programmation classique, une taille peut être négative :

> ### Programmation classique, pas de contrôle
> (TailleMoi <- -1.84)

[1]  -1.84

En programmation objet, on peut préciser que les tailles négatives n'existent pas :

> ### Programmation objet, contrôle
> setValidity ("IMC",
+     function(object){
+         if(object@taille<0){
+              return("Taille négative")
+          } else {
+              return(TRUE)
+          }
+      }
+ )

Class "IMC" [in ".GlobalEnv"]
Slots :

Name :    poids   taille
Class : numeric  numeric

> new("IMC", poids =85, taille = -1.84)

Error in validObject(.Object) :
   invalid class "IMC" object :
Taille négative

Héritage : la programmation objet permet de définir un objet comme héritier des propriétés d'un autre objet, devenant ainsi son fils. L'objet fils bénéficie ainsi de tout ce qui existe pour l'objet. Par exemple, on souhaite affiner un peu nos diagnostics en fonction du sexe de la personne. Nous allons donc définir un nouvel objet, IMCplus, qui contiendra trois valeurs : poids, taille et sexe. Les deux premières variables sont les mêmes que celles de l'objet IMC. Nous allons donc définir l'objet IMCplus comme héritier de l'objet IMC. Il pourra ainsi bénéficier de la fonction show telle que nous l'avons définie pour IMC et cela, sans aucun travail supplémentaire, puisque IMCplus hérite de IMC :

> ### Définition de l'héritier
> setClass("IMCplus",
+     representation(sexe ="character"),
+     contains ="IMC"
+ )

[1]  "IMCplus"

> ### Création d'un objet
> lui <- new("IMCplus", taille =1.76, poids =84, sexe ="Homme")
> ### Affichage qui utilise ce qui a été défini pour 'IMC'
> lui

IMC = 27.11777

La puissance de cette caractéristique apparaîtra plus clairement au chapitre 9Chapitre 9 - Héritage.

Encapsulation : enfin, la programmation objet permet de définir tous les outils composant un objet et de les enfermer dans une boîte, puis de ne plus avoir à s'en occuper. Cela s'appelle l'encapsulation. Les voitures fournissent un bon exemple d'encapsulation : une fois le capot refermé, on n'a plus besoin de connaître les détails de la mécanique pour rouler. De même, une fois l'objet terminé et refermé, un utilisateur n'a pas à s'inquiéter de son fonctionnement interne. Mieux, concernant les voitures, il n'est pas possible de se tromper et de mettre de l'essence dans le radiateur puisque le radiateur n'est pas accessible. De même, l'encapsulation permet de protéger ce qui doit l'être en ne laissant accessible que ce qui ne risque rien.

Vous êtes en train de lire un manuel de programmation objet et donc, d'apprendre une nouvelle méthode. Sachez qu'il n'existe pas « une » mais « des » manières de programmer : à ce sujet, les informaticiens ne sont pas toujours d'accord entre eux.

Ce livre suit une certaine vision, celle de son auteur. Des gens très compétents sont d'accord, d'autres le sont moins… Y a-t-il une vérité et si oui, où se trouve-t-elle ? Mystère. Néanmoins, pour essayer de donner une vision la plus large possible, il arrivera que ce livre vous présente plusieurs points de vue, celui de l'auteur, mais aussi celui de lecteurs qui ont réagi à ce qu'ils lisaient et qui ont fait valoir une autre vision des choses.

Quand les hommes ont commencé à envoyer des fusées dans l'espace(3) et qu'elles ont explosé en plein vol, ils ont écrasé une petite larme et ont cherché les causes de l'échec. Comme il fallait bien brûler quelqu'un, ils ont cherché un coupable. Et ils ont trouvé… les informaticiens. « C'est pas d'not' faute, ont déclaré les informaticiens tout marris, c'est un fait avéré intrinsèque aux ordinateurs : tous les programmes sont bogués ! » Sauf que dans le cas présent, la facture du bogue était plutôt salée…

Des gens très forts et très intelligents ont donc cherché des moyens de rendre la programmation moins boguée. Ils ont fabriqué de nouveaux langages et défini des règles de programmation. On appelle ça la programmation propre ou les bonnes pratiques. Certaines opérations, certaines pratiques, certaines manières de programmer sont donc qualifiées de bonnes, belles ou propres ; d'autres, au rebours, sont qualifiées de mauvaises, dangereuses, impropres voire sales (le terme exact consacré par les informaticiens est crade…). Il ne s'agit pas là de jugements de valeur, ce sont simplement des qualificatifs qui indiquent que ce type de programmation favorise l'apparition d'erreurs dans le code. Donc à éviter d'urgence.

Mais tout le monde ne partage pas ce point de vue : « On a néanmoins besoin des langages ultraflexibles et peu contraints, précise un relecteur, parce qu'ils rendent certaines applications faciles à programmer alors que les langages propres ne les gèrent pas ou mal. Dans ce genre de cas, utiliser un langage propre revient un peu à prendre un marteau-piqueur pour écraser une noix. En particulier, écrire le cœur d'un programme en C (au lieu de R) peut accroître la rapidité d'exécution par un facteur 10 ou 20. »

C'est vrai. Mais tout dépend du niveau du programmeur : à haut niveau, pour ceux qui ne font pas d'erreur, l'efficacité peut primer sur la propreté. À notre niveau, il me paraît surtout important de programmer proprement pour résoudre le problème principal : programmer sans bogue.

Les attributs sont simplement des variables typées. Une variable typée est une variable dont on a fixé la nature une bonne fois pour toutes. Dans R, on peut écrire poids <- 62 (à ce stade, poids est un numeric) puis poids <- "bonjour" (poids est devenu un character). Le type de la variable poids peut changer.

En programmation objet, il ne sera pas possible de changer le type des attributs en cours de programmation(4). Cela semble être une contrainte, c'est en fait une sécurité. En effet, si une variable a été créée pour contenir un poids, elle n'a aucune raison de recevoir une chaîne de caractères… sauf erreur de programmation.

On distingue quatre types d'opérations à faire sur les objets :

• méthodes de création : entrent dans cette catégorie toutes les méthodes permettant de créer un objet. La plus importante s'appelle le constructeur. Mais son utilisation est un peu rugueuse pour l'utilisateur. Le programmeur écrit donc des méthodes faciles d'accès pour créer un objet à partir de données, d'un fichier ou à partir d'un autre objet (par exemple numeric ou read.csv2) ;
• validation : en programmation objet, il est possible de vérifier que les attributs respectent certaines contraintes. Il est également possible de créer des attributs à partir de calculs faits sur les autres attributs. Tout cela rentre dans la validation d'objet ;
• manipulation des attributs : modifier et lire les attributs n'est pas aussi anodin que dans la programmation classique. Aussi, dédie-t-on des méthodes à la manipulation des attributs (par exemple names et names<-) ;
• Autres : tout ce qui précède constitue une sorte de « minimum légal » à programmer pour chaque objet. Restent ensuite les méthodes spécifiques à l'objet, en particulier les méthodes d'affichage et les méthodes effectuant des calculs.

Les méthodes sont des fonctions typées. Le type d'une fonction est la juxtaposition de deux types : son type entrée et son type sortie.

• Le type-entrée est simplement l'ensemble des types des arguments de la fonction. Par exemple, la fonction trace prend pour argument une matrice, son type-entrée est donc matrix.
• Le type-sortie est le type de ce que la fonction retourne. Par exemple, la fonction trace retourne un nombre, son type-sortie est donc numeric.

Finalement, le type d'une fonction est (type-entree,type-sortie). On le note Type-Sortie <- fonction(TypeEntree).

Par exemple, le type de la fonction trace est numeric <- trace(matrix).