Benjamin m'a demandé de clarifier ma position, j'ai donc modifié mon post précédent et ajouté d'autres réflexions.
Bob Martin est l'auteur d'un excellent livre intitulé Clean Code. Dans ce livre, il y a un chapitre (Chapitre 6) appelé Objets et structures de données, dans lequel il traite des différences les plus importantes entre les objets et les structures de données. Il explique que nous devons choisir entre eux, car les mélanger est une très mauvaise idée.
Cette confusion conduit parfois à des structures hybrides malheureuses à mi-objet et à moitié structure de données. Ils ont des fonctions qui font des choses significatives, et ils ont aussi des variables publiques ou des accesseurs et des mutateurs publics qui, à toutes fins utiles, rendent les variables privées publiques, ce qui incite d'autres fonctions externes à les utiliser de la même manière qu'un programme procédural utiliserait un structure de données.4 De tels hybrides rendent difficile l'ajout de nouvelles fonctions mais également l'ajout de nouvelles structures de données. Ils sont les pires des deux mondes. Évitez de les créer. Ils indiquent une conception confuse dont les auteurs ne savent pas - ou pire encore, ignorent s'ils ont besoin de protection contre les fonctions ou les types.
Je pense que DOM est un exemple de ces hybrides d’objets et de structures de données. Par exemple, par DOM, nous écrivons des codes comme celui-ci:
el.appendChild(node);
el.childNodes;
// bleeding internals
el.setAttribute(attr, val);
el.attributes;
// bleeding internals
el.style.color;
// at least this is okay
el = document.createElement(tag);
doc = document.implementation.createHTMLDocument();
// document is both a factory and a tree root
DOM doit clairement être une structure de données plutôt qu’un hybride.
el.childNodes.add(node);
// or el.childNodes[el.childNodes.length] = node;
el.childNodes;
el.attributes.put(attr, val);
// or el.attributes[attr] = val;
el.attributes;
el.style.get("color");
// or el.style.color;
factory = new HtmlNodeFactory();
el = factory.createElement(document, tag);
doc = factory.createDocument();
Le framework jQuery est un ensemble de procédures permettant de sélectionner et de modifier une collection de noeuds DOM et d'effectuer de nombreuses autres tâches. Comme Laurent l'a souligné dans son message, jQuery est à peu près pareil:
html(select("#body"), "<p>hello</p>");
Les développeurs de jQuery ont fusionné toutes ces procédures en une seule classe, responsable de toutes les fonctionnalités énumérées ci-dessus. Donc, cela viole clairement le principe de responsabilité unique et constitue donc un objet divin. La seule chose qui ne casse rien, c'est une classe autonome qui fonctionne sur une seule structure de données (la collection de nœuds DOM). Si nous ajoutions des sous-classes jQuery ou une autre structure de données, le projet s'effondrerait très rapidement. Donc je ne pense pas que nous puissions parler oo par jQuery c'est plutôt procédural que oo malgré le fait qu'il définit une classe.
Ce que Laurent prétend être un non-sens complet:
Alors qu'est-ce que tout cela signifie? Ce jQuery (comme LINQ) n'est pas l'anti-modèle d'objet de Dieu. C'est plutôt un cas d'un modèle très respecté appelé le décorateur.
Le modèle Decorator consiste à ajouter de nouvelles fonctionnalités en conservant l'interface et en ne modifiant pas les classes existantes. Par exemple:
Vous pouvez définir 2 classes qui implémentent la même interface, mais avec une implémentation complètement différente:
/**
* @interface
*/
var Something = function (){};
/**
* @argument {string} arg1 The first argument.
* @argument {string} arg2 The second argument.
*/
Something.prototype.doSomething = function (arg1, arg2){};
/**
* @class
* @implements {Something}
*/
var A = function (){
// ...
};
/**
* @argument {string} arg1 The first argument.
* @argument {string} arg2 The second argument.
*/
A.prototype.doSomething = function (arg1, arg2){
// doSomething implementation of A
};
/**
* @class
* @implements {Something}
*/
var B = function (){
// ...
};
/**
* @argument {string} arg1 The first argument.
* @argument {string} arg2 The second argument.
*/
B.prototype.doSomething = function (arg1, arg2){
// doSomething implementation of B
// it is completely different from the implementation of A
// that's why it cannot be a sub-class of A
};
Si certaines méthodes utilisent uniquement l'interface commune, vous pouvez définir un ou plusieurs décorateurs au lieu de copier-coller le même code entre A et B. Vous pouvez utiliser ces décorateurs même dans une structure imbriquée.
/**
* @class
* @implements {Something}
* @argument {Something} something The decorated object.
*/
var SomethingDecorator = function (something){
this.something = something;
// ...
};
/**
* @argument {string} arg1 The first argument.
* @argument {string} arg2 The second argument.
*/
SomethingDecorator.prototype.doSomething = function (arg1, arg2){
return this.something.doSomething(arg1, arg2);
};
/**
* A new method which can be common by A and B.
*
* @argument {function} done The callback.
* @argument {string} arg1 The first argument.
* @argument {string} arg2 The second argument.
*/
SomethingDecorator.prototype.doSomethingDelayed = function (done, arg1, arg2){
var err, res;
setTimeout(function (){
try {
res = this.doSomething(o.arg1, o.arg2);
} catch (e) {
err = e;
}
callback(err, res);
}, 1000);
};
Vous pouvez donc remplacer les instances originales par les instances de décorateur dans un code de niveau d'abstraction plus élevé.
function decorateWithManyFeatures(something){
var d1 = new SomethingDecorator(something);
var d2 = new AnotherSomethingDecorator(d1);
// ...
return dn;
}
var a = new A();
var b = new B();
var decoratedA = decorateWithManyFeatures(a);
var decoratedB = decorateWithManyFeatures(b);
decoratedA.doSomethingDelayed(...);
decoratedB.doSomethingDelayed(...);
La conclusion que jQuery n'est décorateur de rien, car elle n'implémente pas la même interface que Array, NodeList ou tout autre objet DOM. Il implémente sa propre interface. Les modules ne sont pas utilisés non plus comme décorateurs, ils remplacent simplement le prototype original. Ainsi, le motif Decorator n’est pas utilisé dans l’ensemble de jQuery lib. La classe jQuery est simplement un énorme adaptateur qui nous permet d'utiliser la même API de nombreux navigateurs différents. D'un point de vue différent, c'est un désordre complet, mais cela n'a pas d'importance, cela fonctionne bien et nous l'utilisons.
$fonction ou unjQueryobjet?