클래스 대신 인터페이스에서 객체 인스턴스를 만드는 이유는 무엇입니까?

클래스 대신 인터페이스에서 객체 인스턴스를 만드는 이유는 무엇입니까?

---

클래스에서 생성 된 인터페이스 인스턴스를 여러 번 보았습니다. 이런 방식으로 인터페이스를 사용하는 이유는 무엇입니까? 파생 클래스의 도움으로 자신 만 만든 Interface 인스턴스이며이 인스턴스를 통해이 인터페이스 멤버에만 액세스 할 수 있습니다. 이것이 어떻게 이점을 제공합니까? 난 너무 혼란 스러워요..

interface IPrint
{
    void Print();
}

class Sample : IPrint
{
    public void Print()
    {
        Console.WriteLine("Print...");
    }

    public void Sample()
    {
        Console.WriteLine("Sample...");
    }
}

class Program
{
    static void Main(string[] args)
    {
        IPrint print = new Sample();
        print.Print();
    }
}

---

인터페이스는 클래스가 무언가를 할 수 있어야한다고 정의합니다. 이것은 작업중인 객체가 원하는 작업을 수행한다는 것을 알고 있음을 의미합니다. OOP의 더 큰 자유와 이점을 제공합니다. 이것은 깊은 주제이지만 매우 기본적인 예는 다음과 같습니다.

public interface IAnimal
{
    string Speak();
}

public class Dog : IAnimal
{
    public string Speak()
    {
        return "Woof, woof";
    }
} 

public class Cat : IAnimal
{
    public string Speak()
    {
        return "Meow";
    }
} 

public class Parrot : IAnimal
{
    public string Speak()
    {
        return "Sqwark!";
    }
} 

그런 다음 원하는 동물을 사용할 수 있습니다!

class Program
{
    static void Main(string[] 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());
    }
}

이것은 또한 Inversion Of Control 과 같은 항목을 가져와 개, 고양이 또는 앵무새를 전달할 수 있으며 그 방법은 어떤 동물인지 알거나 돌보지 않고 항상 작동합니다.

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

그러면 실제 동물이 아닌 모의 객체를 사용할 수 있기 때문에 ShoutLoud 단위를 테스트 할 수 있습니다. 기본적으로 코드를 견고하고 단단하게 결합하는 대신 유연하고 동적으로 만듭니다.

또한 Matthew의 질문을 확장합니다. C #에서는 하나의 기본 클래스에서만 상속 할 수 있지만 여러 인터페이스를 가질 수 있습니다. 따라서 다음을 가질 수 있습니다.

public class Dog : IAnimal, IMammal, ICarnivor

이를 통해 작은 인터페이스 (권장)를 구축 할 수 있으므로 항목이 수행 할 수있는 작업을 최대한 제어 할 수 있습니다.

---

Using an interface this way gives you the ability to create methods that use standard template of the interface. So here you might have many classes of printer that all inherit from IPrinter

class SamsungPrinter : IPrinter
{
    // Stuff and interface members.
}

class SonyPrinter : IPrinter
{
    // Stuff and interface members.
}

interface IPrinter
{
    void Print();
}

So for each type SamsungPrinter, SonyPrinter, etc. you can pre-process using something like

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

You know from inheriting from IPrinter and using that type in the method parameters that you can always safely use the Print method on what ever object is passed.

Of course there are many other uses for using interfaces. One example of their use is in design patterns, in particular the Factory and Strategy patterns. The description of which and examples can be found here.

I hope this helps.

---

But how does this differ from, for example, using a base class with virtual methods?

You are all in the assumption that one programmer or one program writes the interface and the classes, but this doesn't always have to be this way.

Maybe you have a complete finished program that works with animals and you have this worked out using:

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

And then some day you download some awesome DLL from nuget that shows pictures for animals. The class library contains a contract - interface - 'IAnimal':

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

The class library also maybe contains :

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

What could you do now ? Your bas class Animal can implement the AwesomeAnimalLibrary IAnimal interface and that's it.

Don't assume that other people will use you abstract base classes but work together using interface contracts.

---

Interface can not have instance because interface implements only signatures of properties or methods. Interface is just a pointer to an instance of some class:

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();

ReferenceURL : https://stackoverflow.com/questions/16832280/why-we-do-create-object-instance-from-interface-instead-of-class