Все ответы здесь были полезны, и я сомневаюсь, что могу добавить что-то новое к смеси, но при чтении ответов здесь, две концепции, упомянутые в двух разных ответах, действительно хорошо вписываются в мою голову, поэтому я составлю свое понимание здесь, в надежде, что это может вам помочь.
У класса есть методы и свойства, и каждый из методов и свойств класса имеет сигнатуру и тело
public int Add(int x, int y)
{
return x + y;
}
Подпись метода Add - это все, что находится перед первым символом фигурных скобок
public int Add(int x, int y)
Цель сигнатуры метода - присвоить имя методу, а также описать его уровень защиты (открытый, защищенный, внутренний, частный и / или виртуальный), который определяет, откуда к методу можно получить доступ в коде
Сигнатура также определяет тип значения, возвращаемого методом, метод Add выше возвращает int и аргументы, которые метод ожидает передать ему вызывающие
Методы, как правило, рассматриваются как нечто, что может сделать объект, приведенный выше пример подразумевает, что класс, определенный методом, работает с числами
Тело метода точно описывает (в коде), как объект выполняет действие, описываемое именем метода. В приведенном выше примере метод add работает, применяя оператор сложения к его параметрам и получая результат.
Одним из основных различий между интерфейсом и классом с точки зрения синтаксиса языка является то, что интерфейс может определять только сигнатуру метода, но не тело метода.
Другими словами, интерфейс может описывать действия (методы) класса, но он никогда не должен описывать, как должно выполняться действие.
Теперь, когда вы надеетесь лучше понять, что такое интерфейс, мы можем перейти ко второй и третьей частям вашего вопроса, когда и зачем мы будем использовать интерфейс в реальной программе.
Один из основных временных интерфейсов, используемых в программе, - это когда кто-то хочет выполнить действие, не желая знать или быть привязанным к специфике того, как эти действия выполняются.
Это очень абстрактное понятие для понимания, так что, возможно, пример может помочь укрепить ваши мысли
Представьте, что вы являетесь автором очень популярного веб-браузера, которым пользуются миллионы людей каждый день, и у вас есть тысячи запросов о функциях от людей, некоторые большие, маленькие, хорошие и такие, как "вернуть <maquee> и <blink> поддержка ".
Поскольку у вас есть только относительно небольшое количество разработчиков и даже меньшее количество часов в день, вы не можете реализовать каждую запрашиваемую функцию самостоятельно, но вы все равно хотите удовлетворить своих клиентов
Итак, вы решаете разрешить пользователям разрабатывать свои собственные плагины, чтобы они могли <blink 'пока коровы не вернутся домой.
Для реализации этого вы можете создать класс плагина, который выглядит следующим образом:
public class Plugin
{
public void Run (PluginHost browser)
{
//do stuff here....
}
}
Но как вы могли бы разумно реализовать этот метод? Вы не можете точно знать, как будет работать каждый возможный будущий плагин
Один из возможных способов обойти это - определить плагин как интерфейс и сделать так, чтобы браузер ссылался на каждый плагин, используя его, например так:
public interface IPlugin
{
void Run(PluginHost browser);
}
public class PluginHost
{
public void RunPlugins (IPlugin[] plugins)
{
foreach plugin in plugins
{
plugin.Run(this);
}
}
}
Обратите внимание, что, как обсуждалось ранее, интерфейс IPlugin описывает метод Run, но не указывает, как Run выполняет свою работу, потому что это специфично для каждого плагина, мы не хотим, чтобы хост плагина интересовался спецификой каждого отдельного плагина.
Чтобы продемонстрировать аспект отношения между классом и интерфейсом «может быть», я напишу плагин для хоста плагинов, который реализует тег <blink>.
public class BlinkPlugin: IPlugin
{
private void MakeTextBlink(string text)
{
//code to make text blink.
}
public void Run(PluginHost browser)
{
MakeTextBlink(browser.CurrentPage.ParsedHtml);
}
}
С этой точки зрения вы можете видеть, что плагин определен в классе с именем BlinkPlugin, но поскольку он также реализует интерфейс IPlugin, на него также можно ссылаться как на объект IPlugin, как это делает класс PluginHost выше, потому что он не знать или заботиться о том, какой тип класса на самом деле, просто это может быть IPlugin
Надеюсь, это помогло, я действительно не собирался быть таким длинным.