Interface dans une langue dynamique?

Question

Interface (ou une classe abstraite avec toutes les méthodes abstraites) est une arme puissante dans un langage statique comme C#, JAVA. Il permet d'utiliser différents types dérivés d'une manière uniforme. Les modèles de conception nous encouragent à utiliser l'interface autant que possible. Toutefois, dans un langage de type dynamique, tous les objets ne sont pas vérifiés pour leur type lors de la compilation. Ils n'ont pas à implémenter une interface à utiliser d'une manière spécifique. Vous avez juste besoin de vous assurer qu'ils ont des méthodes (attributs) définies. Cela rend l'interface non nécessaire, ou du moins pas aussi utile que dans un langage statique.

Un langage dynamique typique (par exemple, ruby) a-t-il une interface? Si c'est le cas, alors quels sont les avantages de l'avoir? Si ce n'est pas le cas, perdons-nous beaucoup de beaux modèles de design qui nécessitent une interface?

Merci.

Answer 1

Je suppose qu'il n'y a pas de réponse unique pour tous les langages dynamiques. En Python, par exemple, il n'y a pas d'interfaces, mais il y a plusieurs héritages. L'utilisation de classes de type interface est toujours utile:

• Les classes de type interface peuvent fournir une implémentation par défaut des méthodes;
• Le typage du canard est bon, mais dans une certaine mesure; parfois, il est utile d'être en mesure d'écrire isinstance(x, SomeType), en particulier lorsque SomeType contient de nombreuses méthodes.

Answer 2

Les interfaces dans les langages dynamiques sont utiles comme documentation des API qui peuvent être vérifiées automatiquement, par ex. par des outils de développement ou affirme à l'exécution.

Par exemple, zope.interface est la norme de facto pour les interfaces en Python. Des projets tels que Zope et Twisted qui exposent d'énormes API à la consommation le trouvent utile, mais pour autant que je sache, il n'est pas beaucoup utilisé en dehors de ce type de projets.

Answer 3

Dans Ruby, qui est un langage typé dynamiquement et qui ne permet qu'un seul héritage, vous pouvez imiter une "interface" via des mixins, plutôt que de polluer la classe avec les méthodes de "l'interface".

Les mixins imitent partiellement l'héritage multiple, permettant à un objet "d'hériter" de plusieurs sources, mais sans l'ambiguïté et la complexité d'avoir réellement plusieurs parents. Il n'y a qu'un seul vrai parent.

Pour implémenter une interface (au sens abstrait, pas un type d'interface réel comme dans les langages statiques) Vous définissez un module comme s'il s'agissait d'une interface dans un langage statique. Vous l'incluez ensuite dans la classe. Voila! Vous avez rassemblé le type de canard dans ce qui est essentiellement une interface.

exemple très simplifié:

module Equippable 
    def weapon 
    "broadsword" 
    end 
end 


class Hero 
    include Equippable 

    def hero_method_1 
    end 

    def hero_method_2 
    end 
end 


class Mount 
    include Equippable 

    def mount_method_1 
    end 
end 


h = Hero.new 
h.weapon # outputs "broadsword" 


m = Mount.new 
m.weapon # outputs "broadsword" 

equippable est l'interface pour Hero, Mont, ainsi que toute autre classe ou modèle qui inclut.

(De toute évidence, l'arme sera très probablement fixé dynamiquement par un initialiseur, qui a été simplifié loin dans cet exemple.)