Catégorie : Développement web

Un bomber­man-like massi­ve­ment multijoueur ? Je ne suis pas convaincu par l’in­té­rêt ludique. Ne pas jouer avec ses amis, ne pas tisser de liens, avoir une inter­ac­tion limi­tée à quelques minutes et faite au hasard, j’ai peur que ça ne remplisse pas de promesses sur le long terme.

Tech­nique­ment par contre c’est inté­res­sant, pas forcé­ment si complexe que ça, mais sacré­ment inté­res­sant. Le jeu dans le navi­ga­teur n’est qu’à ses débuts.

Je déteste avoir à program­mer ou utili­ser des acces­seurs. Voilà, c’est dit.

Sérieu­se­ment, qui a eu l’idée de faire des méthodes getX() et setX() ? Dans le meilleur des cas c’est pénible a écrire et diffi­cile à lire.

Qu’on ne me parle pas d’en­cap­su­la­tion, ces méthodes arti­fi­cielles sont tout sauf un besoin d’en­cap­su­la­tion. C’est même exac­te­ment le contraire de l’en­cap­su­la­tion : C’est parce que je n’ai pas à savoir si un attri­but est en accès direct ou non que je n’ai pas à utili­ser d’ac­ces­seurs.

Il n’est pas besoin d’im­pac­ter la manière dont on appelle les attri­buts d’un objet pour diffé­ren­cier l’in­ter­face publique et les données internes. De nombreux langages on trouvé une manière élégante de gérer les acces­seurs au niveau du langage au lieu de faire faire des pirouettes à l’uti­li­sa­teur. Un des gros avan­tages c’est qu’on ne commence à défi­nir des méthodes d’ac­ces­seur que quand on en a vrai­ment l’uti­lité, pas « partout, au cas où pour plus tard ».

Donc, quand il s’agit de migrer un attri­but autre­fois en accès direct, en Javas­cript :

A = { 
  get b() { return this._b; },
  set b(val) { return this._b = val;} 
};
// ou 

A.__defineGetter__("b", function() { return this._b; };
A.__defineSetter__("b", function(val) { return this._b = val; };

en Ruby :

class A
  def b
    @b
  end
  def b=(val)
    @b = val
  end
end

en Python :

class X(object):
  def getb(self):
    return self._b
  def setb(self, val):
    self._b = val
  b = property(getb, setb)

# ou mieux :

class X(object):
  @property
  def b(self):
    return self._b
  @b.setter
  def b(self, val):
    self._b = val

Sérieu­se­ment, c’est moins de complexité pour démar­rer du code (pas besoin de déve­lop­per des acces­seurs passe-plat au cas où on en aurait besoin plus tard, on peut s’en occu­per unique­ment quand le besoin arrive), et c’est plus de clarté pour tout ce qui utilise notre code (et là le gain est immense même si ça semble juste quelques carac­tères). Je n’ima­gine pas de m’en passer dans les langages où ça existe.

Si vous utili­sez des getter et setter passes-plat, c’est soit votre code qui est mauvais, soit votre langage qui est bridé (soit que vous utili­sez consciem­ment un langage bas niveau). Dans les deux premiers cas il y a quelque chose à repen­ser.

Bien entendu PHP reste à la traine, sous prétexte de simpli­cité (allez comprendre).

Et si nous dépas­sions les posi­tions de prin­cipe ?

Pour faire une mise en page web « respon­sive », des gens biens me décon­seillent de me servir des tailles des diffé­rents appa­reils pour imagi­ner les paliers sur lesquels modi­fier l’agen­ce­ment. L’idée est de travailler sur le contenu et d’ima­gi­ner ce qui est le plus perti­nent pour le contenu, indé­pen­dam­ment des appa­reils sur le marché, qui vont de toutes façons évoluer.

Oui, ok, en théo­rie. Main­te­nant il est temps de travailler la pratique.

Je peux faire une opti­mi­sa­tion ou un nouvel agen­ce­ment à chaque fois que l’es­pace dispo­nible me permet d’ap­por­ter un peu de valeur ajou­tée. Je fini­rai avec une multi­tude de paliers diffé­rents. Certains me deman­de­ront du temps, peut être beau­coup, alors qu’ils ne repré­sentent quasi­ment aucun visi­teur. Autant dire que j’au­rai perdu du temps.

À l’in­verse, je peux prévoir unique­ment quelques paliers prin­ci­paux et lais­ser les marges ou tailles s’adap­ter parce que mon contenu le permet. Ce sera correct et lisible partout mais peut être que tel ou tel type d’ap­pa­reil repré­sente beau­coup de visi­teurs et qu’un palier ou qu’une opti­mi­sa­tion supplé­men­taire aurait apporté un retour sur inves­tis­se­ment signi­fi­ca­tif.

Au final je vais devoir faire des choix de palier non seule­ment en fonc­tion de mon contenu, de l’er­go­no­mie visée et du temps dispo­nible, mais aussi en fonc­tion des visi­teurs et de leur maté­riel. C’est une clas­sique ques­tion de retour sur inves­tis­se­ment, de ratio entre la valeur ajou­tée et l’in­ves­tis­se­ment néces­saire : Je veux que ce soit correct partout, mais je veux concen­ter mes efforts supplé­men­taires là où c’est le plus utile et visible.

Même sans toucher au nombre de paliers, l’er­go­no­mie et les conte­nus ne dictent pas toujours un palier très précis. Je peux fina­le­ment viser un peu plus tôt ou un peu plus tard sans que ça ne change grand chose, j’ap­por­te­rai juste une solu­tion légè­re­ment diffé­rente. Tel ou tel appa­reil risque de se retrou­ver proche d’un palier et avoir connais­sance de cette proxi­mité me permet un quick-win au niveau de la valeur ajou­tée qu’il serait dommage de rater.

Bien évidem­ment c’est une réflexion qui dépend en partie des appa­reils, de la répar­ti­tion des utili­sa­teurs et des prévi­sions tels que nous en dispo­sons aujourd’­hui. Cela peut chan­ger, et cela chan­gera. Si je prends correc­te­ment en compte le design et l’er­go­no­mie alors le rendu restera correct. Peut être pas autant opti­misé qu’au départ, mais pas moins bon que si je ne prends pas du tout en compte les appa­reils et utili­sa­teurs au départ.