Quels sont les effets secondaires de la programmation, de toute façon ?

Chaque fois que nous parlons de certains concepts de programmation, je pense qu’il est important de prendre du recul par rapport aux détails dont nous discutons et de regarder les choses dans le contexte d’une vue d’ensemble.

Certains modules introduisent des effets secondaires ; certains ne le font pas. C’est bon.

Par exemple, hier, j’ai brièvement abordé l’idée de programmer des effets secondaires, mais je l’ai fait en parlant de l’utilisation des PSR. Et pour ceux qui s’intéressent simplement aux aspects de la programmation dans un sens plus général, il est également important de les comprendre.

N’oubliez pas que l’idée d’effets secondaires telle qu’énoncée dans le PSR-1 est :

Un fichier DEVRAIT déclarer de nouveaux symboles (classes, fonctions, constantes, etc.) et ne provoquer aucun autre effet secondaire, ou il DEVRAIT exécuter une logique avec des effets secondaires, mais NE DEVRAIT PAS faire les deux.

Dans cet article, je ne suis pas tellement intéressé à discuter de la logique avec des effets secondaires (car il y a des moments où des effets secondaires se produiront). Au lieu de cela, je suis plus préoccupé par la compréhension des effets secondaires de la programmation (ce qu’ils sont, ce qu’il faut éviter, etc.).

Après tout, parler d’effets secondaires dans un contexte peut signifier une chose alors qu’en programmation, cela peut en signifier une autre.

Programmation des effets secondaires

D’accord, donc toute l’idée ou la définition d’un effet secondaire générique est simple, n’est-ce pas?

un effet secondaire, généralement indésirable, d’un médicament ou d’un traitement médical.

Supprimez tout l’aspect traitement, et vous vous retrouvez avec un "effet secondaire, … indésirable". Bon, voici la partie potentiellement déroutante :

• nous choisissons d’inclure un fichier,
• nous savons ce que fait le fichier,
• ainsi, si nous savons ce que nous incluons et ce qu’il fait, comment peut-il introduire quelque chose d’indésirable ?

Du moins, c’est comme ça que je l’entends souvent lorsqu’il s’agit de parler d’effets secondaires. En programmation, j’ai toujours généralisé les effets secondaires comme tout ce qui modifie l’état du programme.

Assez facile, non?

Effets secondaires dans WordPress

Alors disons que vous travaillez avec WordPress, parce que c’est ce que je fais et écris sur 🙂, et nous avons un fichier qui est responsable de l’ajout d’un élément de sous-menu à l’un des menus de niveau supérieur existants.

Cette classe pourrait être relativement simple en ce sens qu’elle encapsule l’appel d’API WordPress approprié, qu’elle se déclenche lorsqu’elle est attachée au crochet [approprié], puis ajoute le sous-menu, comme prévu.

Mais disons que soit cette classe, une méthode dans la classe, ou incluant un fichier que cette classe ajoute également du JavaScript ou des styles qui modifient l’état de l’élément de sous-menu de sorte qu’il est mis en surbrillance, il se comporte comme s’il avait été "cliqué" ou il fait quelque chose que le programme ou l’utilisateur n’a pas l’intention de faire.

Ce serait un effet secondaire dans la mesure où cela changerait l’état du programme.

Que doit faire le module ?

Cette classe elle-même devrait faire une chose :

Le principe de responsabilité unique est un principe de programmation informatique qui stipule que chaque module ou classe doit avoir la responsabilité d’une seule partie de la fonctionnalité fournie par le logiciel, et que cette responsabilité doit être entièrement encapsulée par la classe.

Mais lorsque nous introduisons quelque chose qui s’ajoute à ce qu’il est censé faire – lorsque nous ajoutons à sa responsabilité ou changeons la chose de base qu’il fait – alors nous avons introduit un effet secondaire.

N’oubliez pas que ce n’est pas intrinsèquement mauvais (selon la définition PSR-1 ci-dessus), mais il est important de reconnaître quand nous le faisons et quand nous ne le faisons pas.

Alors, comment ajoutons-nous des fonctionnalités ?

Je pense que la question naturelle est que si nous voulons ajouter des fonctionnalités à un programme qui modifie son état, comment le faisons-nous (et est-ce faux) ?

D’abord, non, ce n’est pas mal. Je veux dire que les programmes ont des états différents basés sur une variété de choses, n’est-ce pas ? Parfois, cela se produit lorsque quelque chose est écrit sur le disque ou dans une base de données ; cela se produit parfois lorsque l’utilisateur clique sur un élément de l’interface utilisateur, et ainsi de suite.

Mais la façon dont ces états se produisent est là où la nature des effets secondaires entre en jeu.

Prenons par exemple l’idée d’un sous-menu. Il est censé faire une chose. Cela ne devrait rien changer d’autre que ce que nous voyons à l’écran.

• Il ne devrait pas écrire dans la base de données,
• Il ne devrait pas configurer d’écouteur d’événement lorsqu’un autre objet ajoute un sous-menu,
• Il ne devrait pas modifier la présentation de quoi que ce soit en dehors de lui-même.
• Etc.

L’ajout de fonctionnalités fonctionne de la même manière : vous introduisez des classes chargées de faire une chose spécifique et vous les laissez le faire. Lorsque ces composants fonctionnent en conjonction les uns avec les autres, vous avez alors un programme fonctionnel dans lequel chaque module (classe/fonction/peu importe) reste dans sa voie, pour ainsi dire.

Qu’est-ce qu’une règle empirique ?

Je suis sûr que beaucoup d’entre vous qui lisez ceci ont votre avis sur ce que sont les effets secondaires et ce qu’ils ne sont pas. Et comme toi, j’ai le mien.

Pense-y de cette façon:

Si vous appelez une méthode et qu’elle renvoie une valeur, puis que vous appelez à nouveau une méthode avec le même ensemble de données, elle doit renvoyer la même valeur.

C’est ainsi que vous savez que votre fonction, classe ou module générique n’a pas d’effets secondaires.

Et, comme pour tout, j’ai fait ces erreurs (et je continuerai probablement) mais c’est une question d’essayer de m’améliorer pour ne pas le faire.

Finalement, cela deviendra la nouvelle norme.