Concepts de programmation fonctionnelle

Le concept clé du modèle de programmation fonctionnelle est que les programmes sont construits en composant et en appliquant des fonctions. Une fonction pure (pure function) est une fonction qui retournera (return) le même résultat à chaque fois pour les mêmes arguments, et il n'y a pas de lecture d'état mutable partagé. Dans ce contexte, les données partagées (shared data) signifient que les données sont disponibles à plusieurs emplacements de programme ou portées (scope), l'état (state) représente les données qui sont mémorisées au fil du temps, et mutable (mutable) signifie qu'il est modifiable. Si les données utilisées par la fonction sont partagées et mutables, il est possible de retourner des résultats différents pour les mêmes arguments. Une fonction pure ne doit pas avoir d'effets secondaires, ce qui signifie qu'elle ne peut pas modifier un état qui ne lui est pas local. Pour cette raison, les programmes fonctionnels n'ont pas d'instructions d'affectation (assignment statement), ce qui est également connu sous le nom de transparence référentielle.

D'autres caractéristiques et fonctionnalités nécessaires qui peuvent manquer dans certains langages impératifs (imperative language) incluent les fonctions de première classe et les fonctions d'ordre supérieur. Une fonction de première classe (first-class function) est une fonction qui peut être assignée comme valeur à une variable (variable). Une fonction d'ordre supérieur (high-order function) est une fonction qui peut prendre une ou plusieurs fonctions de première classe comme arguments. Elle peut également retourner des fonctions comme résultats, ce qui donne à une fonction la capacité d'appliquer des fonctions à ses arguments une par une. Ceci est très utile pour rendre le code à la fois plus flexible et plus simple. Cela encourage la création de fonctions plus petites qui ne s'occupent que d'une partie d'une tâche plus importante, ce qui contribue également grandement à la maintenabilité (maintainability).

Évaluation de la programmation fonctionnelle

De la même manière que vous effectuez des tâches répétitives chaque jour, la programmation fonctionnelle traite les fonctions utilisées pour exécuter ces tâches comme des citoyens de premier ordre. Parmi les avantages de la répétition, on peut citer le fait de rendre les programmes plus faciles à comprendre pour le programmeur et de les raccourcir. Certains inconvénients de la programmation fonctionnelle sont la nécessité de déplacer les données à travers les fonctions, une implémentation efficace est difficile (mais pas impossible), et de nouveaux tableaux (array) doivent être créés lorsque les données d'un élément (element) sont modifiées.

Encapsulation

Les langages POO contiennent des fonctionnalités pour implémenter l'encapsulation ; ils sont autonomes et permettent le masquage des données. Ces fonctionnalités incluent des règles de portée, par exemple, la définition de variables et de méthodes au sein de classes et l'utilisation de modificateurs d'accès (access modifier).

Les langages orientés objet ont souvent des constructeurs, et certains ont des destructeurs qui supportent l'encapsulation. Un constructeur (constructor) est une méthode spécialisée qui est appelée pour instancier l'objet. Très souvent, les constructeurs ont des paramètres qui peuvent être utilisés pour initialiser les valeurs des attributs avec des arguments qui leur sont passés afin que les variables ne soient pas directement accédées ou assignées. Un destructeur (destructor) est utilisé pour détruire l'objet instancié et récupérer sa mémoire comme en C++. Java et les HLL modernes disposent d'un programme d'arrière-plan pour le ramasse-miettes (garbage collection) qui détruit automatiquement les objets et récupère la mémoire lorsqu'il n'y a plus de références à ceux-ci dans le code.

Ils emploient également l'utilisation de méthodes pour définir et retourner les valeurs des variables afin qu'elles ne soient pas directement accédées. Le masquage des données est en outre activé dans certains HLL modernes tels que Java. Cela implique un processus d'arrière-plan pour le ramasse-miettes qui détruit automatiquement les objets et récupère la mémoire lorsqu'il n'y a plus de références à ceux-ci dans le code.

Le masquage des données est l'un des principaux objectifs de la POO qui relève de l'encapsulation. Son but est de traiter les détails d'implémentation dans une classe ou un objet qui sont sans importance pour les utilisateurs de la classe ou de l'objet. Ils n'ont besoin de savoir que comment les utiliser ; par conséquent, les détails sont cachés et ne fournissent que ce qui est nécessaire dans son interface publique (public interface).

La plupart des langages POO ont les mots-clés (keyword) public et private. Ils sont utilisés pour marquer la visibilité et l'accès aux attributs et méthodes par des zones de code qui sont en dehors du code de la classe elle-même. Nous les appelons modificateurs d'accès. Un membre (member) est un attribut ou une méthode encapsulé au sein d'une classe ou d'un objet. Un membre public fait partie de l'interface publique, et un membre privé est caché. Le code Java suivant est une définition de classe abrégée qui démontre le concept :

public class Rectangle {
   // attributes
   private double length;
   private double width;
   // constructors
   public Rectangle(double length, double width) {
      . . . . .
   }
   // methods
   public double getLength() {
      return length;
   }
   . . . . .
   public double getArea() {
      . . . . .
   }
}

La classe elle-même est publique, accordant l'accès à elle et à son contenu. Les attributs sont tous privés, ne faisant pas partie de l'interface publique. Dans ce contexte, le concepteur a décidé de ne pas autoriser l'accès direct à ces attributs de l'extérieur. Au lieu de cela, ils sont accédés par des méthodes publiques, dont certaines ne sont pas montrées. Les méthodes que nous employons, appelées accesseurs (getters) et mutateurs (setters), peuvent présenter nos données au monde extérieur de la manière que nous choisissons. La méthode peut être décrite comme une méthode utilitaire qui peut fournir des données utiles au public afin qu'il n'ait pas à les calculer lui-même.

Héritage

La Figure 7.21 illustre l'implémentation de l'héritage simple (single inheritance), la méthodologie utilisée par la plupart des HLL POO modernes. Les classes et les objets ne peuvent hériter que d'un seul parent.

Figure 7.21 Ce diagramme UML montre l'héritage simple en Java. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Nous appelons la classe parente la super-classe (superclass) dans une relation d'héritage et les classes enfants une sous-classe (subclass) qui contient les attributs et les méthodes de sa classe parente. Dans cette illustration, tous les attributs de Véhicule sont hérités par la Voiture et les autres sous-classes avec les mêmes modificateurs d'accès exacts. Il en va de même pour toutes les méthodes.

Seul C++ implémente l'héritage multiple (multiple inheritance), héritant des attributs et des méthodes de plus d'un parent. Ce concept est extrêmement complexe et peut causer des problèmes majeurs d'implémentation. Un exemple est lorsque les deux parents ont une méthode du même nom et qu'il ne peut être spécifié laquelle est héritée ou redéfinie. Pour implémenter un comportement partagé par plusieurs classes parentes, Java a introduit l'interface, qui peut être implémentée en C++ pour résoudre les problèmes d'héritage multiple.

Une interface (interface) ressemble à une définition de classe, mais c'est une collection de méthodes uniquement. Ces méthodes sont construites comme des méthodes abstraites. Une méthode abstraite (abstract method) est déclarée sans bloc de code (code block) pour l'implémentation. Une classe peut utiliser une ou plusieurs interfaces. Voici une définition de classe Java qui utilise une interface :

public class Rectangle implements geometryMath{
}

L'interface agit comme un contrat avec le programmeur. Si le programmeur déclare qu'une classe implémente une interface, il est requis que la classe fournisse le code d'implémentation pour les fonctions qui composent l'ensemble de l'interface. Une redéfinition (override) définit une autre méthode avec le même nom et modifie sa signature. La redéfinition forme une instance concrète de ce qui était une méthode abstraite dans l'interface. Les interfaces apparaissent en Java, C#, Go ou Ruby, et sont l'approche dominante, supplantant le véritable héritage multiple.

Polymorphisme

La caractéristique de la POO selon laquelle les méthodes héritées peuvent s'exécuter de différentes manières dans différentes sous-classes en fonction de leur contexte est appelée polymorphisme (polymorphism). Ceci est implémenté en redéfinissant les méthodes héritées dans une sous-classe ou celles d'une interface implémentée. Dans le diagramme UML, le comportement de lancement d'une voiture est très différent de celui d'un voilier ou d'une fusée. Le comportement résultant dépend du contexte car il n'est pas défini au moment de la compilation. C'est plutôt l'exécution qui décide quoi faire lorsqu'elle rencontre un objet basé sur sa classe. Le comportement se transforme et produit des résultats différents pour les mêmes appels de méthode selon l'objet en question, ce qui est la liaison dynamique de méthode (dynamic method binding) ou la liaison tardive (late binding), ce qui signifie que toutes les méthodes sont résolues dynamiquement à l'exécution, et non par le compilateur (compiler).

Évaluation de la POO

Rappelez-vous que certains langages comme Java et C# sont entièrement orientés objet ; d'autres comme C++ sont des hybrides de procédural et d'orienté objet, et certains sont en voie de devenir entièrement orientés objet comme JavaScript, PHP et Python. Toute évaluation du paradigme orienté objet doit être effectuée dans le contexte de la position d'un langage particulier sur l'échelle de l'orientation objet.

Avantages de la POO :

• Forte abstraction (abstraction) avec la capacité de réutiliser le code efficacement
• Productivité accrue du développement logiciel et maintenabilité (maintainability)
• Développement logiciel plus rapide, donc coût de développement inférieur car il est très efficace pour le développement parallèle
• S'adapte bien au parallélisme (parallelism), où les programmes peuvent avoir plus d'une partie du code s'exécutant simultanément
• Logiciel plus cohérent — la liaison dynamique de méthode produisant le polymorphisme est un mandat selon lequel les sous-classes implémentent les mêmes comportements avec des différences

Inconvénients de la POO :

• Courbe d'apprentissage abrupte pour maîtriser la POO
• La création de programmes peut être complexe
• Exécution plus lente due à un plus grand nombre d'instructions générées par le compilateur

Conditions de concurrence

Lorsque l'état d'un programme et ses comportements ne sont pas synchronisés, une condition de concurrence (race condition) se produit. Les conditions de concurrence sont une question de synchronisation car des anomalies peuvent survenir lorsque nous ne savons pas quel processus se terminera en premier ou quelle partie du programme est en cours d'exécution. Nous pouvons exercer un contrôle sur le moment où un processus se met en pause ou se termine dans le scénario "exécuter jusqu'à blocage" où un certain mécanisme met un fil d'exécution en pause. Cette situation n'est pas toujours négative ; les conditions de concurrence peuvent parfois être positives en permettant au multithreading de concourir sans restriction pour l'attention du processeur.

Dans de nombreuses situations multitâches, nous voulons éviter les conditions de concurrence et exercer un certain degré de contrôle de l'exécution ; en d'autres termes, nous voulons synchroniser les fils d'exécution dans des situations entrelacées ou parallèles.

Synchronisation

L'établissement de la coopération entre les fils d'exécution, ou synchronisation, est souvent géré en déterminant d'abord quels segments de code forment une section critique. Une section critique est un bloc de code qui influence les résultats de la concurrence ou du parallélisme. Un exemple simple pourrait être un programme d'employé dans lequel une fonction (function) concurrente calcule le salaire de l'employé et une autre imprime le chèque de paie. La fonction d'impression ne peut pas procéder à l'inscription du montant sur le chèque tant que la fonction de calcul ne retourne (return) pas le montant. D'autres situations nécessitant l'utilisation de sections critiques sont les suivantes :

• Lorsque plusieurs fils d'exécution ont besoin d'accéder à de la mémoire partagée ou à des ressources, et que le moment de l'accès peut être critique pour le résultat final
• Lorsque les processus doivent communiquer entre eux pour avancer, souvent implémenté comme un passage de messages entre processus
• Cas où tous les processus concurrents doivent se terminer avant que l'exécution du programme ne se poursuive
• Cas où un ou plusieurs des processus ont besoin d'un résultat d'un autre processus

Comme visible dans la Figure 7.22, lorsque les processus s'exécutent dans un ordre demandé, la synchronisation se produit.

Figure 7.22 Lorsque plusieurs fils d'exécution cherchent à accéder à une section critique, ils ont besoin de synchronisation. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Puisque l'objectif est d'éviter les conditions de concurrence négatives, nous ne voulons pas sur-synchroniser car cela diminue le degré de parallélisme dont nous avons besoin pour la performance.

Implémentation de la synchronisation

La synchronisation doit être implémentée avec soin pour éviter les situations que la synchronisation elle-même peut causer :

• famine (starvation) : lorsqu'un processus doit attendre pour entrer dans une section critique, mais que les autres processus monopolisent la section, et que le processus en attente n'obtient pas de temps processeur.
• attente active (busy waiting) : lorsqu'un processus cherche continuellement à savoir s'il a accès à une section critique, prenant du temps processeur à tous les processus.
• interblocage : lorsque plusieurs fils d'exécution ont besoin d'une section critique qui est monopolisée par l'un des processus.

Java est connu pour sa forte implémentation de la synchronisation. Lorsqu'une méthode ou un bloc de code est marqué comme synchronisé, il est garanti qu'un seul fil d'exécution peut s'y exécuter simultanément. Tout autre fil d'exécution essayant d'entrer dans la méthode ou le bloc de code est bloqué jusqu'à ce que l'occurrence en cours quitte la méthode ou le bloc. Le code Java suivant montre la syntaxe d'utilisation du mot-clé (keyword) sur une méthode :

public synchronized void calcAverage() {
   // all of the method code
}

Une méthode synchronisée est coordonnée sur l'objet qui possède la méthode. En POO, chaque instance de l'objet peut avoir sa propre synchronisation. Par exemple, nous pourrions avoir une classe Voiture qui possède une méthode appelée start(). Chaque instance de voiture que nous construisons a sa propre copie de la méthode ; par conséquent, si nous démarrons une voiture, aucun autre processus ne peut démarrer cette voiture particulière. Mais si nous avons plus d'une voiture, une autre peut être démarrée concurremment.

Le code Java suivant montre la syntaxe d'utilisation du mot-clé sur un bloc de code au sein d'une méthode :

synchronized (this) {
   // critical section
}

Ce code s'exécutera exactement comme s'il s'agissait d'une méthode synchronisée. Ce mot-clé fait référence à l'objet courant, donc ce code se synchronise également sur l'objet qui possède le bloc de code. Cette utilisation offre une granularité et des temps d'exécution beaucoup plus efficaces.

Un autre outil puissant pour la synchronisation en Java est de déclarer une classe entière comme un fil d'exécution, ce qui signifie que toute la classe se trouve dans un seul fil d'exécution. Il existe deux façons de le faire. La première consiste à faire hériter la classe de la classe Thread de l'API Java :

public class SomeThread extends Thread {
}

L'autre façon est de faire implémenter une interface de l'API par la classe :

public class SomeThread implements Runnable {
}

L'une ou l'autre de ces méthodologies donne accès aux méthodes utiles de la classe Thread qui sont héritées et peuvent être redéfinies pour prendre en charge la situation particulière. L'interface forme un contrat avec le programmeur pour implémenter ces méthodes afin de prendre en charge la tâche particulière.

Un objet Thread est contrôlé par un ordonnanceur basé sur les priorités. Certaines des méthodes les plus importantes à la disposition du programmeur sont les suivantes :

• start() : provoque le démarrage de l'exécution du fil d'exécution
• yield() : indique à l'ordonnanceur de fils d'exécution que le fil d'exécution actuel est prêt à céder son contrôle
• sleep(int time) : fait hiberner temporairement le fil d'exécution en cours d'exécution pendant un nombre spécifié de millisecondes
• setPriority(int priority) : modifie la priorité du fil d'exécution actuel
• join(int time) : attend le nombre de millisecondes indiqué avant de commander l'arrêt du fil d'exécution