Почему мы используем Интерфейс? Это только для Стандартизации? [закрытый]

Основная причина, по которой интерфейсы используются в языках типа C#/Java, заключается в том, что эти языки не поддерживают множественное (классовое) наследование (см. В чем именно проблема множественного наследования?).

Но реализация множественного (интерфейса) наследуется, позволяя использовать классы разными способами.

Интерфейс используется для описания того, что может делать реализованная вещь. Таким образом, у вас есть возможность рассматривать несколько объектов, реализующих один и тот же интерфейс, как тип этого интерфейса.

Например:

public interface IMyInterface{
    public void DoFirst();
    public int DoSecond();
}


public class A : IMyInterface{
   //class has to implement DoFirst and DoSecond
   public void DoFirst(){
     Console.WriteLine("Blubb1");  
   }

   public int DoSecond(){
     Console.WriteLine("Blubb2");
     return 2;  
   }
}

public class B : IMyInterface{
   //class has to implement DoFirst and DoSecond
   public void DoFirst(){
     Console.WriteLine("Blibb1");  
   }

   public int DoSecond(){
     Console.WriteLine("Blibb2");  
     return 4;
   }
}

Классы реализуют интерфейс несколькими способами. Но вы можете использовать их как IMyInterface. Например:

public static void DoMethodsInInterface(IMyInterface inter){
    inter.DoFirst();
    inter.DoSecond();
}


public static void main(){

   DoMethodsInInterface(new A());
   DoMethodsInInterface(new B());
   //Or use it in a List
   List<IMyInterface> interlist = new List<IMyInterface>();
   interlist.Add(new A());
   interlist.Add(new B());
   foreach(IMyInterface inter in interlist){
      inter.DoFirst();
   }

}

Я надеюсь, что это немного проясняет, почему интерфейсы полезны.

Почему мы используем интерфейсы?

Некоторые языки реализуют полиморфные вызовы метода с использованием VTables и отказаться от большинства типов информации, что делает его жестким , не , чтобы определить интерфейсы.

Так что когда-то мы просто используем интерфейсы, потому что языковой дизайн требует этого.

Вот вид высокого уровня...

Интерфейсы играют большую роль в концепции Сокрытия информации .

Они в основном помогают скрыть детали реализации вашего класса, так что вызывающий класс не зависит от этой реализации. Поэтому, используя интерфейсы, вы можете модифицировать реализацию без изменения вызывающего класса. Все это, в свою очередь, ограничивает сложность вашего кода и делает его более простым в обслуживании в долгосрочной перспективе.

Когда я впервые начал понимать интерфейсы, они были объяснены мне как "контракт, который предоставляет описание вашего класса". Не уверен, что это поможет вам, но если вы думаете об интерфейсе для автомобиля можно сказать, что это диски , ломается , и поворачивает . Так что до тех пор, пока это приводит меня из точки А в точку Б, мне не нужно знать, как эти функции реализованы.

интерфейсы несколько неловко. Они поддерживают дизайн по контракту, просто полагая, что же имя и реализованный интерфейс означает одинаковое поведение. Это работает только благодаря документации API, она должна быть проверена на человека. Это делает интерфейсы слишком слабыми. Один из способов обойти, это может быть формальным спецификациями. С другой стороны, интерфейсы слишком сильные, слишком строгие. Вы не можете развивать интерфейсы, которые часто получают повторное использование. Это решается протоколами - механизмом на динамических языках, которые отправляют сообщения (методы вызова) и когда это сообщение не поддерживается приемником, стандартный обратный вызов вызывается. Наличие конкретных протоколов с ограничениями будет имхо лучше.

Подумайте Удаление ...

Есть клиент и сервер, участвующий здесь. Позвольте сказать, что они физически разделены Интернетом. Клиент вызывает метод, фактическое исполнение которого происходит на сервере. С точки зрения клиента клиент ничего не знает об объекте на сервере, который выполняет выполнение. Однако он знает, какой метод позвонить. Поскольку при создании клиентской программы мы выставлены только на интерфейс (или договор). Мы не подвержены воздействию всего объекта, который на самом деле живет на сервере. Попробуйте сделать несколько демонстрационных приложений в .NET Remoting, и вы поймете все остальное. Счастливое программирование.

Начав с интерфейса, вы можете реализовать прокси , что позволит использовать ленивый загрузка или выполнение некоторых проверок при вызове методов конкретной реализации.

Это для взаимодействия :), чтобы вы могли взаимодействовать между собой, это полезно, когда у вас есть

• несколько реализаций одного и того же материала
• , когда вы применяете интерфейс к нескольким различным классам, потому что вам нужно какое-то соглашение, которое эти классы могут что-то делать или иметь некоторую функциональность