Почему мы используем интерфейс?
Это только для стандартизации?
Почему мы используем интерфейс?
Это только для стандартизации?
Ответы:
Аналогия 1 : подобно американскому космическому шаттлу, российский космический корабль «Союз» и китайский «Шэньчжоу-5» могут стыковаться с Международной космической станцией, потому что они реализуют один и тот же стыковочный интерфейс. (Это всего лишь пример - я не знаю, правда ли это в реальной жизни, но давайте оставим наше недоверие ради примера)
Аналогия 2 : Например, вы можете подключить к домашнему компьютеру различные компьютерные мониторы. Вы можете подключить к нему телевизор во всю стену, старую ЭЛТ (толстую), 20-дюймовый плоский экран или машину Брайля, чтобы слепые могли "видеть" на ощупь. Эти различные устройства совместимы с вашими компьютер, потому что все они согласны со стандартами интерфейса.
Подробная информация об интерфейсах C #. С интерфейсами C # / OOP вы делаете то же самое, но в невидимом / виртуальном мире.
Вы правы насчет стандартизации , но также гибкости , масштабируемости , расширяемости , ремонтопригодности , повторного использования , тестируемости и мощности .
(Чем больше вы будете использовать программные интерфейсы, тем больше будут понятны эти «модные слова». И всегда учитывайте интерфейсы в реальном мире, потому что они одинаково хорошо нам помогают.)
standardization, but also flexibility, scalability, extensibility, maintainability, reusability, testability and power.
Интерфейс используется для описания того, что может сделать реализованная вещь. Таким образом, у вас есть возможность рассматривать несколько объектов, реализующих один и тот же интерфейс, как тип этого интерфейса.
Например:
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();
}
}
Надеюсь, это проясняет, почему интерфейсы полезны.
Woozle
, любой код, который хочет принять ссылку на любой из классов Woozle
, должен знать, с каким классом он имеет дело, и сможет только Woozle
классы, о которых он знает. Напротив, если оба класса реализуются IWoozler
, то код, который предоставляется любому, IWoozler
может Woozle
без необходимости знать его точный тип.
Это для взаимодействия :), чтобы вы могли взаимодействовать между собой, это полезно, когда у вас есть
Вот вид на высоком уровне ...
Интерфейсы играют большую роль в концепции сокрытия информации .
В основном они помогают скрыть детали реализации вашего класса, чтобы вызывающий класс не зависел от этой реализации. Следовательно, используя интерфейсы, вы можете изменить реализацию, не меняя вызывающий класс. Все это, в свою очередь, ограничивает сложность вашего кода и упрощает его поддержку в долгосрочной перспективе.
Когда я только начал разбираться в интерфейсах, мне объяснили, что это «контракт, который предоставляет описание вашего класса». Не уверен, что это поможет вам, но если вы думаете об интерфейсе для автомобиля, вы можете сказать, что он ездит , ломается и поворачивает . Так что, пока он ведет меня из точки А в точку Б, мне действительно не нужно знать, как эти функции реализованы.
Основная причина использования интерфейсов в таких языках, как C # / Java, заключается в том, что эти языки не поддерживают множественное (классовое) наследование (см. Какова точная проблема множественного наследования? ).
Но разрешена множественная (интерфейсная) реализация, позволяющая использовать классы по-разному.
Интерфейсы несколько неудобные. Они поддерживают дизайн по контракту, просто полагая, что то же имя и реализованный интерфейс означают одинаковое поведение. Это работает только благодаря документации API, это должно быть проверено людьми. Это делает интерфейсы слишком слабыми. Один из способов обойти это - формальные спецификации. С другой стороны, интерфейсы слишком сильны, слишком строги. Вы не можете развивать интерфейсы, которые часто мешают повторному использованию. Это решается протоколами - механизмом на динамических языках, которые отправляют сообщения (методы вызова), и когда это сообщение не поддерживается получателем, вызывается стандартный обратный вызов. Имхо было бы лучше иметь конкретные протоколы с ограничениями.
Подумайте об удалении ...
Здесь задействованы клиент и сервер. Допустим, они физически разделены Интернетом. Клиент вызывает метод, фактическое выполнение которого происходит на сервере. С точки зрения клиента, клиент ничего не знает об объекте на сервере, который выполняет выполнение. Однако он знает, какой метод вызвать. Потому что при создании клиентской программы мы видим только интерфейс (или контракт). Нам не доступен весь объект, который фактически живет на сервере. Попробуйте сделать несколько демонстрационных приложений в .net remoting, и вы разберетесь с остальным. Удачного программирования.
Почему мы используем интерфейсы?
Некоторые языки реализуют вызовы полиморфных методов с использованием vtables и отбрасывают большую часть информации о типе, что затрудняет не для определения интерфейсов.
Поэтому иногда мы просто используем интерфейсы, потому что этого требует дизайн языка.
Интерфейс предоставляет модальный прототип, который просто содержит декларацию функциональности определенного поведения.
и если вы хотите реализовать это поведение в классе, тогда вы должны реализовать этот интерфейс в классе, тогда класс будет иметь эту функциональность поведения или он может иметь несколько вариантов поведения.
потому что класс может реализовывать несколько интерфейсов.
Если кто-то похож на меня и учится на примерах и действиях, а не только на объяснениях, вот код ....
Я нашел эту реализацию нейронной сети на C #, включая загрузку проекта, которая использует интерфейсы элегантным и полезным образом: