Как я буду знать, когда создать интерфейс?

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

А хороший пример этого в мире.NET интерфейс IDisposable, который используется на любых классах Microsoft, которые используют системные ресурсы, которые должны быть вручную выпущены. Это требует, чтобы класс, реализовывая его имел Расположение () метод.

(Расположение () метод также называет конструкция языка использования для VB.NET и C#, который только работает над IDisposable, s)

Имеет в виду, что можно проверить, реализует ли объект определенный интерфейс при помощи конструкций такой как TypeOf ... Is (VB.NET), is (C#), instanceof (Java), и т.д.

Это также позволяет Вам выполнять Ложное поблочное тестирование (.Net). Если Ваш класс использует интерфейс, можно дразнить объект в поблочном тестировании и легко протестировать логику (на самом деле не поражая базу данных или веб-сервис, и т.д.).

http://www.nmock.org/

Как несколько человек, вероятно, уже ответили, интерфейсы могут использоваться для осуществления определенных поведений между классами, которые не реализуют те поведения тот же путь. Таким образом путем реализации интерфейса Вы говорите, что Ваш класс имеет поведение интерфейса. Интерфейс IAnimal не был бы типичным интерфейсом, потому что Собака, CAT, Птица, и т.д. классы являются типами животных и должны, вероятно, расширить его, который является случаем наследования. Вместо этого интерфейс был бы больше похож на поведение животных в этом случае, такое как IRunnable, IFlyable, ITrainable, и т.д.

, Интерфейсы хороши для многих вещей, одной из ключевых вещей является pluggability. Например, объявление метода, который имеет параметр Списка, будет допускать что-либо, что реализует интерфейс List, который будет передан в, позволяя разработчику удалить и включить различный список в более позднее время, не имея необходимость переписывать тонну кода.

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

я рекомендовал бы читать главу по интерфейсам в Дизайн Java Coad, Mayfield и Керна. Они объясняют его немного лучше, чем средний вводный текст. Если Вы не используете Java, можно просто считать начало главы, которая является просто главным образом понятиями.

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

существует интерфейс между электрическими устройствами и электросетью - это набор соглашений о форме разъемов и сокетов и напряжений/токов через них. Если Вы захотите реализовать новое электрическое устройство, пока Ваш разъем следует правилам, то он будет в состоянии получить сервисы от сети. Это делает расширяемость очень легкий и удаляет, или понижает затраты на координацию : Вы не должны уведомлять поставщика электроэнергии о том, как Ваше новое устройство работает, и придите к отдельному соглашению о том, как включить Ваше новое устройство в сеть.

Страны имеют стандартные ширины рельсовой колеи. Это позволяет разделение труда между машиностроительными компаниями, которые положили направляющие и машиностроительные компании, которые создают поезда для работы тех направляющих, и оно позволяет железнодорожным компаниям к замена, и обновите поезда, не повторно проектируя целую систему.

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

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

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

Самый легкий пример для предоставления является чем-то как Платежные Процессоры. (PayPal, PDS и т.д.).

Говорят, что Вы создаете интерфейс IPaymentProcessor, который имеет методы ProcessACH и ProcessCreditCard.

можно теперь реализовать конкретную реализацию PayPal. Создание тех методов назвать PayPal определенными функциями.

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

Пример кода (комбинация Andrew с дополнительным моим в what-is-the-purpose-of-interfaces), который также излагает доводы о почему интерфейс вместо абстрактного класса на языках без поддержки множественного наследования (c# и Java):

interface ILogger
{
    void Log();
}
class FileLogger : ILogger
{
    public void Log() { }
}
class DataBaseLogger : ILogger
{
    public void Log() { }
}
public class MySpecialLogger : SpecialLoggerBase, ILogger
{
    public void Log() { }
}

Уведомление, что FileLogger и DataBaseLogger не нужен интерфейс (мог быть абстрактный базовый класс Регистратора). Но полагайте, что Вы обязаны использовать сторонний регистратор, который вынуждает Вас использовать базовый класс (позволяет, говорят, что он представляет защищенные методы Вы Потребность использовать). Поскольку язык не поддерживает множественное наследование, Вы не будете в состоянии использовать подход абстрактного базового класса.

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

Необходимо определить интерфейс, как только необходимо вызвать поведение для класса.

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

Другим практическим примером является ActionListener (или Выполнимый) интерфейс. Вы реализовали бы их, когда необходимо отслеживать конкретное событие. Поэтому необходимо обеспечить реализацию для actionPerformed(Event e) метод в классе (или подкласс). Точно так же для интерфейса Runnable, Вы обеспечиваете реализацию для public void run() метод.

кроме того, можно было реализовать эти интерфейсы любое количество классов.

Другой экземпляр, где Интерфейсы используются (в Java) должен реализовать множественное наследование, предлагаемое в C++.

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

я не могу сказать Вам, почему Вам нужны интерфейсы, но я могу дать Вам список того, где мы используем их в нашем текущем проекте:

1. В нашей сменной модели, мы загружаем плагины интерфейсом и предоставляем тот интерфейс сменным писателям для приспосабливания.

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

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

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

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

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

существует много других причин, что я нашел для укрепления хорошей практики рефакторинга к интерфейсам, но поблочное тестирование / насмешка вещи было тем, что обеспечило начальную букву "ага момент" практического опыта.

РЕДАКТИРОВАНИЕ : Для разъяснения с поблочным тестированием и насмешкой, у меня всегда есть две реализации - реальная, конкретная реализация и альтернативная ложная реализация, используемая в тестировании. Как только у Вас есть две реализации, значение интерфейса становится очевидным - имеют дело с ним с точки зрения интерфейса, таким образом, можно заменить реализацию в любое время. В этом случае я заменяю его ложным интерфейсом. Я знаю, что могу сделать это без фактического интерфейса, если мой класс создается правильно, но использование фактического интерфейса укрепляет это и делает его инструментом для очистки (более ясный читателю). Без этого импульса я не думаю, что ценил бы значение интерфейсов начиная с большинства моих классов только, когда-либо имейте единственную конкретную реализацию.

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

пример я всегда даю кому-то, то, если у Вас есть класс Парусной лодки и класс Гадюки. Они наследовали класс Лодки и Автомобильный класс соответственно. Теперь скажите, что необходимо циклично выполниться через все эти объекты и назвать их Drive() метод. В то время как Вы могли записать некоторый код как следующее:

if(myObject is Boat)
    ((Boat)myObject).Drive()
else
    if (myObject is Car)
        ((Car)myObject).Drive()

было бы намного намного более просто записать:

((IDrivable)myObject).Drive()

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

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

Если Вы просмотрите блоки Платформы.NET и выполните развертку в базовые классы для какого-либо из стандартных объектов, Вы заметите много интерфейсов (участники, названные как ISomeName).

Интерфейсы в основном для реализации платформ, больших или маленьких. Я чувствовал то же самое по отношению к интерфейсам, пока я не хотел записать мою собственную платформу. Я также нашел, что понимание интерфейсов помогло мне изучить платформы намного более быстро. Момент, для которого Вы хотите записать более изящное решение примерно что-либо, Вы найдете, что интерфейс имеет много смысла. Это похоже на метод разрешения классу надеть соответствующую одежду для задания. Что еще более важно, интерфейсы позволяют системам становиться намного большим количеством самодокументирования, потому что сложные объекты становятся менее сложными, когда класс реализует интерфейсы, который помогает категоризировать его функциональность.

Классы реализуют интерфейсы, когда они хотят быть в состоянии участвовать в платформе явно или неявно. Например, IDisposable является единым интерфейсом, который обеспечивает сигнатуру метода для популярного, и полезные Располагают () метод. В платформе все, что Вы или другой разработчик должны знать о классе, - то, что, если это реализует IDisposable, тогда Вы знаете, что ((IDisposable) myObject).Dispose () доступно, чтобы быть названным в целях очистки.

КЛАССИЧЕСКИЙ ПРИМЕР: не реализовывая интерфейс IDisposable, Вы не можете использовать "использование ()" конструкция ключевого слова в C#, потому что это требует, чтобы любой объект, указанный в качестве параметра, мог быть неявно брошен к IDisposable.

СЛОЖНЫЙ ПРИМЕР: более сложным примером была бы Система. ComponentModel. Класс компонента. Этот класс реализует и IDisposable и IComponent. Большинство, если не все, объекты.NET, которым связали визуального разработчика с ними, реализуют IComponent так, чтобы IDE был в состоянии взаимодействовать с компонентом.

ЗАКЛЮЧЕНИЕ: Поскольку Вы становитесь более знакомыми с Платформой.NET, первая вещь, которую Вы сделаете при обнаружении с новым классом в Обозревателе объектов или в Отражателе.NET, который (свободный) инструмент ( http://www.red-gate.com/products/reflector/ ) должен проверить для наблюдения, какой класс, который это наследовало от и также интерфейсы, которые это реализует. Отражатель.NET еще лучше, чем Обозреватель объектов, потому что это позволяет Вам видеть Производные классы также. Это позволяет Вам узнавать обо всех объектах, которые происходят из конкретного класса, таким образом, потенциально узнавая о функциональности платформы, которую Вы не знали, существовал. Это особенно значительно, когда обновлено, или новые пространства имен добавляются к Платформе.NET.

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

существует компромисс здесь, как обычно: гибкость по пригодности для обслуживания. Какой более важен? Нет никаких ответов - это зависит от проекта. Но просто помните, что каждый программные обеспечения должны будут сохраняться...

Так мой совет: не используйте интерфейсы, пока Вам действительно не будут нужны они. (С Visual Studio можно извлечь интерфейс из существующего класса через 2 секунды - так не спешите.)

Однако когда необходимо создать интерфейс?

я делаю это, когда я осуществляю рефакторинг метод что внезапно потребность обработать два или больше подобных класса. Я тогда создаю интерфейс, присваиваю этот интерфейс двум (или больше) подобные классы, и я изменяюсь, тип параметра метода (замените тип класса интерфейсным типом).

И это работает: o)

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

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

С уважением, Sylvain.

Используйте интерфейсы, когда реализации той же функциональности будут отличаться.

Использование краткий обзор/базовые классы, когда необходимо совместно использовать общую конкретную реализацию.

Думайте об интерфейсе как Контракт. Это - способ сказать, "Эти классы должны следовать за ними ряд правил".

Так в примере IAnimal, это - способ сказать, "Я ДОЛЖЕН быть в состоянии назвать Выполнение, Обход, и т.д. на классах, которые реализуют IAnimal".

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

public void RunThenWalk(Monkey m) {
    m.Run();
    m.Walk();
}

public void RunThenWalk(Dog d) {
    d.Run();
    d.Walk();
}

... и повторение, которое для всех объектов, которые Вы знаете, может работать и идти. Однако с Вашим интерфейсом IAnimal, можно определить функцию однажды следующим образом:

public void RunThenWalk(IAnimal a) {
    a.Run();
    a.Walk();
}

Путем программирования против интерфейса, Вы по существу доверяете классы для реализации намерения интерфейса. Таким образом в нашем примере, мысль, "Я не забочусь как они Выполнение и Обход, пока они Выполнение и Обход. Мой RunThenWalk будет допустим, пока они выполняют то соглашение. Это функционирует отлично, не зная ничто больше о классе".

существует также хорошее обсуждение в этот связанный вопрос .

Мне нравится ответ Jimmy много, но я чувствую, что должен добавить что-то к нему. Ключ ко всему этому является "способным" в IProcess, который в состоянии . Это указывает на возможность (или свойство, но значение "внутреннего качества", не в смысле свойств C#) объекта, который реализует интерфейс. IAnimal, вероятно, не, хорошим примером для интерфейса, но IWalkable мог бы быть хороший интерфейс, чтобы иметь, если Ваша система имеет много вещей, которые могут идти. Вам можно было бы получить классы из Животного, такие как Собака, Корова, Рыба, Змея. Первые два, вероятно, реализовали бы IWalkable, последние два не идут, таким образом, они не были бы. Теперь Вы спрашиваете, "почему не только имеют другой суперкласс, WalkingAnimal, из которого происходят Собака и Корова?". Ответ - когда у Вас есть что-то полностью вне дерева наследования, которое также может идти, такие как робот. Робот реализовал бы IWalkable, но вероятно не произойдет из Животного. Если Вы хотите список вещей, которые могут идти, Вы вводите его как IWalkable, и можно поместить всех животных обхода плюс роботы в списке.

Теперь замена IWalkable с чем-то больше программного-обеспечения-y как IPersistable и аналогия становятся намного ближе к тому, что Вы видели бы в реальной программе.

Я использовал интерфейсы время от времени, и вот мое последнее использование (имена были обобщены):

у меня есть набор пользовательских элементов управления на WinForm, который должен сохранить данные к моему бизнес-объекту. Один подход должен назвать каждое управление отдельно:

myBusinessObject.Save(controlA.Data);
myBusinessObject.Save(controlB.Data);
myBusinessObject.Save(controlC.Data);

проблема с этой реализацией состоит в том, что любое время, я добавляю управление, в которое я должен войти мой, "Сохраняют Данные" метод и добавляют новое управление.

я изменил свои средства управления для реализации интерфейса ISaveable, который имеет метод, SaveToBusinessObject (...) поэтому теперь мой "Сохраняют Данные" метод, просто выполняет итерации посредством средств управления и если это находит тот, который является ISaveable, это называет SaveToBusinessObject. Таким образом, теперь то, когда новое управление необходимо, все, что кто-то должен сделать, реализовать ISaveable в том объекте (и никогда не касаться другого класса).

foreach(Control c in Controls)
{
  ISaveable s = c as ISaveable;

  if( s != null )
      s.SaveToBusinessObject(myBusinessObject);
}

часто неосуществленное преимущество для интерфейсов - то, что Вы локализуете модификации. После того, как определенный, Вы будете редко изменять полный поток приложения, но Вы будете часто вносить изменения на уровне детализации. Когда Вы сохраните детали в конкретных объектах, изменение в ProcessA не будет влиять на изменение в ProcessB. (Базовые классы также приносят Вам эту пользу.)

РЕДАКТИРОВАНИЕ: Другое преимущество является спецификой в действиях. Как в моем примере, все, что я хочу сделать, сохраняют данные; я не забочусь, какое управление это или если это может сделать что-либо еще - я просто хочу знать, могу ли я сохранить данные в управлении. Это делает мой код сохранения довольно ясным - нет никаких проверок, чтобы видеть, является ли это текст, числовой, булев или безотносительно потому что пользовательский элемент управления обрабатывает все это.

Интерфейс используется для множества целей

1. Использование в полиморфном поведении. Если вы хотите вызвать определенные методы дочернего класса с интерфейсом, имеющим ссылку на дочерний класс.

2. Наличие контракта с классами для реализации всех методов там, где это необходимо, как и наиболее распространенное использование с COM-объектами, где класс-оболочка создается для библиотеки DLL, наследующей интерфейс; эти методы вызываются за кулисами, и вам просто нужно их реализовать, но с той же структурой, которая определена в COM DLL, о которой вы можете узнать только через интерфейс, который они предоставляют.

3. Чтобы уменьшить использование памяти путем загрузки определенных методов в класс. Например, если у вас есть три бизнес-объекта, и они реализованы в одном классе, вы можете использовать три интерфейса.

Например, IUser, IOrder, IOrderItem

public interface IUser()
{

void AddUser(string name ,string fname);

}

// Same for IOrder and IOrderItem
//


public class  BusinessLayer: IUser, IOrder, IOrderItem

{    
    public void AddUser(string name ,string fname)
    {
        // Do stuffs here.
    }

    // All methods from all interfaces must be implemented.

}

Если вы хотите добавить только пользователя, сделайте следующее:

IUser user = new (IUser)BusinessLayer();

// It will load  all methods into memory which are declared in the IUser interface.

user.AddUser();