Adopter les bonnes pratiques

1. Principe

Lorsque nous développons, nous éviterons toujours d’exposer un trop grand nombre de fonctions ou de variables dans l’espace de noms global afin d’éviter des conflits de nom. Cela signifie de ne donner l’accès qu’à ce qui est utile et masquer tout le reste. C’est un peu le principe d’une boîte noire avec des entrées et sorties bien définies mais la mécanique interne reste cachée.

C’est d’autant plus important si le code risque d’être utilisé dans d’autres contextes. Le problème vient que nous avons l’habitude d’ajouter des fonctions dans nos fichiers sans prendre en compte la réutilisation. Notre projet devenant plus conséquent, il devient de plus en plus difficile à gérer. Associer deux codes peut alors provoquer des conflits qui ne sont pas forcément visibles au premier coup d’œil et le résultat devient incertain.

Pour limiter les conflits de nom, nous ajouterons un contexte supplémentaire (une sorte de super contexte) qui garantira que nos fonctions et variables ne pourront être altérées/utilisées accidentellement. Cet espace de noms est une sorte de conteneur de noms. Un nom n’a alors de sens que par rapport à son espace de noms. Invoquer une fonction qui n’est pas dans l’espace de noms attendu devient donc impossible.

Chaque code ayant son espace de noms, il n’y a plus de risque de collisions associé à un code appartenant à un autre espace de noms.

Un espace de noms est une possibilité associée à de nombreux langages. Dans le langage Java, par exemple, le mot-clé package sert à effectuer la déclaration, de même en C# avec namespace. En JavaScript, nous n’avons malheureusement pas de mot-clé pour cet usage mais nous avons d’autres astuces tout aussi puissantes pour l’obtenir.

Ce principe est important pour la qualité de vos programmes. Une fois que l’aurez compris, il deviendra naturel et votre développement s’améliorera d’autant plus.

Plus votre programme est important et plus vous avez besoin d’espaces de noms. C’est la dimension qui en impose l’usage. Prendre en compte l’espace...

1. Présentation

Le concept de module découle de la structure précédente. L’idée est de proposer un format universel aux briques de fonctionnalités. Un module représente une partie indépendante de notre code. Par exemple nous pourrions avoir un module chargé d’un type de calcul ou un module représentant un composant graphique. Un module ne doit pas être confondu avec une fonction ; il est au-dessus de la fonction et masque toutes les fonctions et propriétés utiles pour rendre un service.

Nous avons vu précédemment que la fonction pouvait servir d’espace de noms protégeant des conflits certaines méthodes ou variables de notre code. Cela a conduit à la conception de notre module :

function monModule { 
   // Définition privée 
   variables ... 
   fonctions ... 
 
   return { 
      // Définition publique 
      propriétés... 
      méthodes... 
   } 
} 

Cette structure peut être employée partout et remplace même vos classes. Nous pourrons également retourner indifféremment un objet unique, un constructeur ou bien une fonction. 

Si par exemple vous voulez obtenir plusieurs instances, dans ce cas, il faut un constructeur qui se chargera de produire les instances à la demande :

function monModule {    
   // Définition privée 
   variables pour toutes les instances... 
   fonctions ... 
 
  // Constructeur intermédiaire pour chaque instance 
  return function() {  
    return {  
      //...

1. Présentation

Si nous souhaitons rendre un module plus accessible, donc facilement exploitable par tous, il faut se conformer à un standard, d’où l’usage de solutions comme ce que propose CommonJS (http://www.commonjs.org/). CommonJS est né en 2009 sous l’impulsion de Kevin Dangoor avec l’idée de pouvoir normaliser certaines API de JavaScript. Comme nous l’avons vu jusqu’ici, JavaScript offre une grande expressivité dans le codage qui s’avère agréable mais qui cache aussi un véritable problème de normalisation et d’interopérabilité.

2. define

Si nous regardons la définition d’un module, il est défini selon CommonJS comme étant :

define( id?, dependencies?, factory); 

define est une fonction proposée par l’API compatible CommonJS servant à décrire un module. Les paramètres de cette fonction (un point d’interrogation est présent pour un paramètre optionnel) sont :

1. Introduction

1. Fonction alert

for ( var i = 10; i >= 0; i -- ) { 
  alert( i ); 
} 

b. Simplification

Nous pouvons alléger ces invocations de cette manière :

var tmp = "" 
for ( var i = 10; i >= 0; i -- ) { 
  tmp += " i = " + i + "\n"; 
} 
alert( tmp ); 

Nous avons bien tracé la variable i et nous n’avons qu’un seul affichage.

L’inconvénient étant encore une question de quantité : à partir d’un certain nombre d’itérations, la hauteur de la fenêtre rend le tout ingérable.

(function( window ) { 
   var trace = ""; 
   window.trace = function( msg ) { 
     trace += msg + "\n"; 
   } 
   window.traceRes = function() { 
     if ( trace ) 
       alert( trace ); 
     trace = ""; 
   } 
} )( window ); ...