En programmation, une interface définit le comportement d'un objet, mais elle ne spécifie pas réellement le comportement. C'est un contrat qui garantira qu'une certaine classe peut faire quelque chose.
Considérez ce morceau de code C # ici:
using System;
public interface IGenerate
{
int Generate();
}
// Dependencies
public class KnownNumber : IGenerate
{
public int Generate()
{
return 5;
}
}
public class SecretNumber : IGenerate
{
public int Generate()
{
return new Random().Next(0, 10);
}
}
// What you care about
class Game
{
public Game(IGenerate generator)
{
Console.WriteLine(generator.Generate())
}
}
new Game(new SecretNumber());
new Game(new KnownNumber());
La classe Game nécessite un numéro secret. Pour le tester, vous souhaitez injecter ce qui sera utilisé comme numéro secret (ce principe est appelé Inversion de Contrôle).
La classe de jeu veut être "ouverte d'esprit" sur ce qui créera réellement le nombre aléatoire, donc elle demandera dans son constructeur "tout ce qui a une méthode Generate".
Tout d'abord, l'interface spécifie les opérations qu'un objet fournira. Il contient juste à quoi il ressemble, mais aucune implémentation réelle n'est donnée. Ce n'est que la signature de la méthode. De manière conventionnelle, les interfaces en C # sont précédées d'un I. Les classes implémentent désormais l'interface IGenerate. Cela signifie que le compilateur s'assurera qu'ils ont tous les deux une méthode qui renvoie un int et qui est appelée Generate. Le jeu est maintenant appelé deux objets différents, chacun implémentant l'interface correcte. D'autres classes produiraient une erreur lors de la construction du code.
Ici, j'ai remarqué l'analogie du plan que vous avez utilisée:
Une classe est généralement considérée comme un modèle pour un objet. Une interface spécifie quelque chose qu'une classe devra faire, donc on pourrait dire qu'il ne s'agit en fait que d'un modèle pour une classe, mais comme une classe n'a pas nécessairement besoin d'une interface, je dirais que cette métaphore est en train de se rompre. Considérez une interface comme un contrat. La classe qui «signe» sera légalement tenue (imposée par la police du compilateur) de se conformer aux termes et conditions du contrat. Cela signifie qu'il devra faire ce qui est spécifié dans l'interface.
Tout cela est dû à la nature statiquement typée de certains langages OO, comme c'est le cas avec Java ou C #. En Python par contre, un autre mécanisme est utilisé:
import random
# Dependencies
class KnownNumber(object):
def generate(self):
return 5
class SecretNumber(object):
def generate(self):
return random.randint(0,10)
# What you care about
class SecretGame(object):
def __init__(self, number_generator):
number = number_generator.generate()
print number
Ici, aucune des classes n'implémente d'interface. Python ne se soucie pas de cela, parce que la SecretGameclasse essaiera simplement d'appeler n'importe quel objet passé. Si l'objet A une méthode generate (), tout va bien. Si ce n'est pas le cas: KAPUTT! Cette erreur ne sera pas vue au moment de la compilation, mais au moment de l'exécution, donc peut-être lorsque votre programme est déjà déployé et en cours d'exécution. C # vous avertirait bien avant que vous ne vous approchiez de cela.
La raison pour laquelle ce mécanisme est utilisé, naïvement déclaré, parce que dans les langues OO, les fonctions ne sont naturellement pas des citoyens de première classe. Comme vous pouvez le voir, KnownNumberetSecretNumber contiennent JUSTE les fonctions pour générer un nombre. On n'a pas vraiment besoin des cours du tout. En Python, par conséquent, on pourrait simplement les jeter et choisir les fonctions seules:
# OO Approach
SecretGame(SecretNumber())
SecretGame(KnownNumber())
# Functional Approach
# Dependencies
class SecretGame(object):
def __init__(self, generate):
number = generate()
print number
SecretGame(lambda: random.randint(0,10))
SecretGame(lambda: 5)
Un lambda est juste une fonction, qui a été déclarée "en ligne, au fur et à mesure". Un délégué est exactement le même en C #:
class Game
{
public Game(Func<int> generate)
{
Console.WriteLine(generate())
}
}
new Game(() => 5);
new Game(() => new Random().Next(0, 10));
Remarque: les derniers exemples n'étaient pas possibles comme ça jusqu'à Java 7. Là, les interfaces étaient votre seul moyen de spécifier ce comportement. Cependant, Java 8 a introduit des expressions lambda afin que l'exemple C # puisse être converti en Java très facilement ( Func<int>devient java.util.function.IntSupplieret =>devient ->).