Comment Commencer à Écrire du Code “Complexe”

Ceci est un article sur la réflexion sur le code que vous écrivez. Tout ce qui est contenu ici est mon opinion et vous devriez toujours considérer la validité de mes opinions en les comparant à de meilleures! Le langage que j’utiliserai est Javascript. Une condition préalable à la compréhension de cet article est de connaître Javascript intermédiaire et de se familiariser avec certains concepts orientés objet. Cet article est inspiré du chapitre 9 de l’excellent livre de Cristina Lopes “Exercices de style de programmation”.

Un modèle vraiment commun dans le code est —

1. Définir un objet simple

var store_item = {
name : 'wonderball'
}

2. Ensuite, pour le préparer à s’afficher sur une page Web, nous exécutons chaque propriété via certaines fonctions.

addExclamationPoint(store_item);
capitalizeName(store_item);function addExclamationPoint(item) {
item.name = item.name + '!';
}function capitalizeName(item) {
// some code to capitalize item.name, cut out for brevity.
}

Et c’est ainsi que nous obtenons souvent des données prêtes à être affichées. Maintenant que notre store_item a un nom en majuscule et un point d’exclamation, nous pouvons l’afficher sur notre page Web sans problème. S’il y a une troisième chose à faire, nous écririons simplement une troisième fonction pour transformer les données et transmettre l’élément comme d’habitude.

Le modèle d’image plus grand que nous avons créé ici est:

Il existe quelques termes fantaisistes pour ce type de programmation tels que “procédural” ou “impératif”, mais je l’appellerais un terme différent: “simple”. C’est une programmation très simple. C’est le type de programmation que tout le monde apprend en premier. Pour les programmes à petite échelle, c’est absolument la meilleure façon de programmer, car les humains savent très bien suivre de 1 à 10 étapes logiques.

Lorsque votre programme devient suffisamment volumineux (plus de 10 transformations avant l’affichage des données), ou qu’une fonction modifie beaucoup d’objets de données (plus de 2), ou que nous avons beaucoup d’instructions IF provoquant une logique de branchement, cette programmation “simple” devient à la place “un gâchis”.

La plupart de chaque projet ou morceau de code devient désordonné. La plupart de la programmation est en fait des codeurs qui trouvent des moyens d’éviter de faire un gâchis, pas des solutions au problème réel de l’affichage des données. Le travail de la programmation consiste à apprendre à écrire du code de telle sorte que nous puissions appliquer 100 transformations sur 100 de données et en faire “pas un gâchis”.

Maintenant, permettez-moi de vous présenter un grand changement au modèle ci-dessus, et considérez que ce que je vais vous montrer est la première étape pour devenir un codeur plus avancé car cela vous sort du codage “simple”. Il vous présente de nouvelles façons de penser à la façon de faire une chose simple comme modifier certaines données pour une page Web. L’objet aura désormais sa propre fonction appelée ‘bind’, et cette fonction sera responsable de la transformation des données.

var store_item = {
name: 'wonderball',
bind: function(func) {
this.name = func(this.name);
return this;
}
}// Here are two functions I'll use to transform the store_item.name, each one now just takes a name and modifies it, neither function has any clue what properties it's changing in store_item anymore.function capitalize(name) {
return name.replace(/\w\S*/g, function(txt) {
return txt.charAt(0).toUpperCase() +
txt.substr(1).toLowerCase();
});
}function addExclamationPoint(name) {
return name + '!';
}store_item.bind(addExclamationPoint).bind(capitalize);

Cette solution se comporte exactement comme le code “simple” d’origine ci-dessus, mais elle semble plus complexe, pourquoi? Parce que pour la tâche simple que nous avons, c’est exagéré, mais quels sont les compromis de cette complexité?

Pour répondre à cela, parlons de ce qui est différent:

1. Nous avons cette fonction ‘bind’ folle, bizarre, qui prend comme argument, pas une nouvelle valeur pour name, mais plutôt une autre fonction, dites quoi maintenant?
2. les fonctions capitalize et addExclamationPoint sont différentes, maintenant elles n’appellent plus item.name directement plus.
3. Nous ne définissons plus de nom avec un ‘=’, nous utilisons plutôt cet étrange store_item.bind(nom_fonction), syntaxe à la place.

Avec ces trois différences, nous devons maintenant nous demander: ce changement est-il meilleur? Peut-être pas si le projet reste aussi petit. Peut-être que oui si le projet devient beaucoup plus grand.

Le changement de clé est que l’objet store_item est désormais responsable de la gestion de son état via la fonction bind. Bien sûr, si vous le vouliez, vous pouvez directement modifier store_item.name , mais l’objet crie pratiquement: “Hé, utilisez ma fonction de liaison pour me changer!”.

Mais maintenant, il est facile de voir un modèle où plusieurs store_items gèrent chacun leur propre état avec le leur.fonction de liaison:

// Three store items, each one with a different state.store_item1.bind(addExclamationPoint).bind(capitalize); //Wonderball!store_item2.bind(capitalize);
//Wonderballstore_item3.bind(addExclamationPoint);
//wonderball!

Nous pouvons créer 100 store_item et gérer leur état assez facilement. Tout ce que nous avons à faire est d’écrire une fonction qui a juste une valeur de retour et d’utiliser celle de notre objet.fonction de liaison.

La magie de ce modèle réside dans la fonction de liaison, alors explorons cela un peu plus maintenant.

// 1. First define the function, and have it take as an argument another function. Taking a function as an argument, instead of data is the core change here. bind: function(func) { // 2. This second line is the secret sauce, it will run the function you passed in with 'this.name' as an argument, and then assign whatever value is returned to this.name. Mull this over. this.name = func(this.name);// 3. Finally, return 'this'. You don't have to have this step in here, but returning 'this' is what allows .bind chainging to happen (.e.g. doing .bind().bind() vs .bind(); .bind();) return this;
}

Donc voilà, nous avons rendu notre code plus complexe, mais nous avons maintenant quelques nouveaux avantages:

1. Un objet modifie maintenant son propre état, et il peut le faire de manière significative en une seule ligne.
2. Les fonctions que nous avons écrites sont plus pures, elles ne modifient pas les propriétés d’un objet comme dans l’exemple ci-dessus, elles prennent simplement une entrée et renvoient une sortie.
3. Nous savons que lorsque nous modifions l’état d’un objet, les fonctions que nous utilisons ne modifieront probablement pas accidentellement l’état d’un autre objet

Mais nous avons également quelques inconvénients:

1. Votre code est nettement moins intuitif pour un nouveau venu maintenant.
2. Pour un petit site, ce code est trop complexe.

Alors quel est le jugement final, est-ce mieux? Pire ? Plus déroutant? (Au début, oui.) Toutes ces questions sont ouvertes, mais je peux dire une chose à coup sûr, considérer et comprendre des modèles comme celui-ci fait partie de l’apprentissage de Javascript et de la croissance en tant que codeur. L’utilisation continue de la manière “simple” de coder pour résoudre les problèmes devient insoutenable après un certain temps. Si vous prenez le temps d’apprendre des façons plus “complexes” de faire les choses, beaucoup de grandes choses se produisent: votre capacité à penser latéralement s’ouvre, vous pouvez lire des types de code plus divers et vous augmentez les façons de penser à résoudre des problèmes. C’est peut-être le vrai avantage d’apprendre cela et d’autres modèles.