Pourquoi nous créons une instance d’object à partir d’Interface au lieu de Class?

J’ai vu plusieurs fois une instance d’interface générée à partir d’une classe. Pourquoi utilise-t-il une interface de cette manière? Une instance Interface créée uniquement à l’aide de la classe dérivée et nous ne pouvons accéder qu’à cette interface membres via cette instance. Comment cela donne-t-il un avantage? Je suis si confus..

interface IPrint { void Print(); } class Sample : IPrint { public void Print() { Console.WriteLine("Print..."); } public void Sample() { Console.WriteLine("Sample..."); } } class Program { static void Main(ssortingng[] args) { IPrint print = new Sample(); print.Print(); } } 

Les interfaces définissent qu’une classe DOIT pouvoir faire quelque chose. Cela signifie que vous savez que l’object sur lequel vous travaillez fera ce que vous voulez pouvoir faire. Il vous permet une plus grande liberté et des avantages de la POO. Ceci est un sujet de fond mais un exemple très simple serait ceci:

 public interface IAnimal { ssortingng Speak(); } public class Dog : IAnimal { public ssortingng Speak() { return "Woof, woof"; } } public class Cat : IAnimal { public ssortingng Speak() { return "Meow"; } } public class Parrot : IAnimal { public ssortingng Speak() { return "Sqwark!"; } } 

Ensuite, vous pourriez utiliser n’importe quel animal que vous aimez!

 class Program { static void Main(ssortingng[] args) { // Writes Woof, Woof IAnimal animal = new Dog(); Console.WriteLine(animal.Speak()); // Now writes Meow animal = new Cat(); Console.WriteLine(animal.Speak()); // Now writes Sqwark etc animal = new Parrot(); Console.WriteLine(animal.Speak()); } } 

Cela vous permet également d’entrer dans des choses comme Inversion Of Control où vous prendrez un object comme ceci et vous pourriez passer un chien, un chat ou un perroquet et la méthode fonctionnerait toujours, ne sachant pas ou s’occupant de quel animal c’était:

 public void ShoutLoud(IAnimal animal) { MessageBox.Show("Shout " + animal.Speak()); } 

Cela rend alors l’ unité ShoutLoud testable car vous pouvez utiliser un object simulé plutôt qu’un animal réel. Cela rend votre code flexible et dynamic plutôt que rigide et étroitement lié.

En outre, en développant la question de Matthew. En C #, vous ne pouvez hériter que d’une classe de base, mais vous pouvez avoir plusieurs interfaces. Donc, vous pourriez avoir:

 public class Dog : IAnimal, IMammal, ICarnivor 

Cela vous permet d’avoir de petites interfaces (recommandées) qui vous permettent ensuite de créer un maximum de contrôle sur ce qu’un élément peut / doit faire.

L’utilisation d’une interface de cette manière vous permet de créer des méthodes utilisant un modèle standard de l’interface. Donc, ici, vous pouvez avoir beaucoup de classes d’imprimante qui héritent toutes d’ IPrinter

 class SamsungPrinter : IPrinter { // Stuff and interface members. } class SonyPrinter : IPrinter { // Stuff and interface members. } interface IPrinter { void Print(); } 

Donc, pour chaque type SamsungPrinter , SonyPrinter , etc., vous pouvez effectuer un prétraitement en utilisant quelque chose comme:

 public static void PreProcessAndPrint(IPrinter printer) { // Do pre-processing or something. printer.Print(); } 

Vous savez en héritant d’ IPrinter et en utilisant ce type dans les parameters de méthode que vous pouvez toujours utiliser en toute sécurité la méthode Print sur tout object transmis.

Bien sûr, il y a beaucoup d’autres utilisations pour utiliser des interfaces. Un exemple de leur utilisation concerne les modèles de conception, en particulier les modèles Factory et Strategy. La description et les exemples peuvent être trouvés ici .

J’espère que ça aide.

Mais en quoi cela diffère-t-il, par exemple, de l’utilisation d’une classe de base avec des méthodes virtuelles?

Vous êtes tous dans l’hypothèse qu’un programmeur ou un programme écrit l’interface et les classes, mais cela ne doit pas toujours être le cas.

Vous avez peut-être un programme complet qui fonctionne avec les animaux et vous avez fait cela en utilisant:

 public abstract class Animal { public abstract ssortingng Speak(); } 

Et puis un jour, vous téléchargez une DLL impressionnante de nuget qui montre des images pour les animaux. La bibliothèque de classes contient un contrat – interface – ‘IAnimal’:

 namespace AwesomeAnimalLibrary { public interface IAnimal { ssortingng AnimalName; } } 

La bibliothèque de classes peut aussi contenir:

 namespace AwesomeAnimalLibrary { public class AnimalPhotos { [Byte] GetPhotos(IAnimal animal); } } 

Que pourriez-vous faire maintenant? Votre classe de base Animal peut implémenter l’interface IAnimal AwesomeAnimalLibrary et c’est tout.

Ne supposez pas que d’autres personnes utiliseront des classes de base abstraites, mais travailleront ensemble à l’aide de contrats d’interface.

L’interface ne peut pas avoir d’instance car l’interface implémente uniquement des signatures de propriétés ou de méthodes. L’interface est juste un pointeur vers une instance d’une classe:

 interface IExample { // method signature void MyMethod(); } public class MyClass : IExample { // method implementation public void MyMethod() { ConsoleWriteline("This is my method"); } } // interface pointing to instance of class IExample ie = new MyClass(); ie.MyMethod();