Il n'y a aucune notion de "cette classe doit avoir ces fonctions" (c'est-à-dire, aucune interface en soi), car:
- L'héritage JavaScript est basé sur des objets, pas sur des classes. Ce n'est pas un gros problème jusqu'à ce que vous réalisiez:
- JavaScript est un langage typé de manière extrêmement dynamique - vous pouvez créer un objet avec les méthodes appropriées, ce qui le rendrait conforme à l'interface, puis indéfinir tout ce qui l'a rendu conforme . Il serait si facile de renverser le système de saisie - même accidentellement! - qu'il ne vaudrait pas la peine d'essayer de créer un système de type en premier lieu.
Au lieu de cela, JavaScript utilise ce qu'on appelle la frappe de canard . (S'il marche comme un canard et quacks comme un canard, pour JS, c'est un canard.) Si votre objet a les méthodes quack (), walk () et fly (), le code peut l'utiliser où il le souhaite un objet qui peut marcher, charlatan et voler, sans nécessiter la mise en œuvre d'une interface "Duckable". L'interface est exactement l'ensemble des fonctions que le code utilise (et les valeurs de retour de ces fonctions), et avec la frappe de canard, vous obtenez cela gratuitement.
Maintenant, cela ne veut pas dire que votre code n'échouera pas à mi-parcours, si vous essayez d'appeler some_dog.quack(); vous obtiendrez une TypeError. Franchement, si vous dites aux chiens de charlatan, vous avez des problèmes légèrement plus importants; la frappe de canard fonctionne mieux lorsque vous gardez tous vos canards dans une rangée, pour ainsi dire, et ne laissez pas les chiens et les canards se mélanger, sauf si vous les traitez comme des animaux génériques. En d'autres termes, même si l'interface est fluide, elle est toujours là; c'est souvent une erreur de passer un chien au code qui s'attend à ce qu'il charlatane et vole en premier lieu.
Mais si vous êtes sûr de faire la bonne chose, vous pouvez contourner le problème des chiens charlatans en testant l'existence d'une méthode particulière avant d'essayer de l'utiliser. Quelque chose comme
if (typeof(someObject.quack) == "function")
{
// This thing can quack
}
Vous pouvez donc vérifier toutes les méthodes que vous pouvez utiliser avant de les utiliser. Cependant, la syntaxe est plutôt moche. Il y a une façon un peu plus jolie:
Object.prototype.can = function(methodName)
{
return ((typeof this[methodName]) == "function");
};
if (someObject.can("quack"))
{
someObject.quack();
}
Il s'agit de JavaScript standard, il devrait donc fonctionner dans n'importe quel interpréteur JS utile. Il a l'avantage supplémentaire de lire comme l'anglais.
Pour les navigateurs modernes (c'est-à-dire à peu près n'importe quel navigateur autre que IE 6-8), il existe même un moyen d'empêcher la propriété d'apparaître dans for...in:
Object.defineProperty(Object.prototype, 'can', {
enumerable: false,
value: function(method) {
return (typeof this[method] === 'function');
}
}
Le problème est que les objets IE7 n'en ont pas .definePropertydu tout, et dans IE8, il ne fonctionnerait que sur les objets hôtes (c'est-à-dire les éléments DOM et autres). Si la compatibilité est un problème, vous ne pouvez pas l'utiliser .defineProperty. (Je ne mentionnerai même pas IE6, car il n'est plus pertinent en dehors de la Chine.)
Un autre problème est que certains styles de codage aiment supposer que tout le monde écrit du mauvais code et interdisent de le modifier Object.prototypeau cas où quelqu'un voudrait l'utiliser aveuglément for...in. Si vous vous souciez de cela ou utilisez du code ( cassé IMO ), essayez une version légèrement différente:
function can(obj, methodName)
{
return ((typeof obj[methodName]) == "function");
}
if (can(someObject, "quack"))
{
someObject.quack();
}