В чем преимущество использования интерфейса? - PullRequest
4 голосов
/ 14 апреля 2011

Какая польза от использования интерфейса?

Я слышал, что он используется вместо множественного наследования, и с ним можно также скрывать данные.

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

В чем разница между explicit interface implementation и implicit interface implementation?

Ответы [ 7 ]

5 голосов
/ 14 апреля 2011

Чтобы решить неявный / явный вопрос, допустим, что два разных интерфейса имеют одно и то же объявление:

interface IBiographicalData

    {
       string LastName
       {
          get;
          set;
       }

    }

    interface ICustomReportData
    {
       string LastName
       {
          get;
          set;
       }
    }

И у вас есть класс, реализующий оба интерфейса:

class Person : IBiographicalData, ICustomReportData
{
    private string lastName;

    public string LastName
    {
        get { return lastName; }
        set { lastName = value; }
    }
}

КлассPerson Неявно реализует оба интерфейса, потому что вы получаете один и тот же вывод со следующим кодом:

Person p = new p();
IBiographicalData iBio = (IBiographicalData)p;
ICustomReportData iCr = (ICustomReportData)p;

Console.WriteLine(p.LastName);
Console.WriteLine(iBio.LastName);
Console.WriteLine(iCr.LastName);

Однако, чтобы явно реализовать, вы можете изменить класс Person какитак:

class Person : IBiographicalData, ICustomReportData
{
    private string lastName;

    public string LastName
    {
        get { return lastName; }
        set { lastName = value; }
    }

    public string ICustomReportData.LastName
    {
        get { return "Last Name:" + lastName; }
        set { lastName = value; }
    }
}

Теперь код:

Console.WriteLine(iCr.LastName);

Будет иметь префикс "Фамилия:".

http://blogs.msdn.com/b/mhop/archive/2006/12/12/implicit-and-explicit-interface-implementations.aspx

2 голосов
/ 14 апреля 2011

Интерфейсы очень полезны для

  • Инъекция зависимостей
  • Инверсия управления
  • Тестовая изоляция
1 голос
/ 14 апреля 2011

В самых основных терминах мы возвращаемся к ООП 101:

Наследование: Объект B "является" типом Объекта A. Поведения и методы, реализованные Объектом A, наследуются, реализация и все (с некоторым пространством для Переопределения) Объектом B.

Интерфейс: Объект A и Объект B представляют собой примеры "Действуй как" абстрактного объекта, представленного общим интерфейсом. Джеймс Гонт использует приведенный выше пример. Другими примерами могут быть IPrintable, IDisposable и т. Д.

Для любого данного класса, который реализует эти Интерфейсы, реализация может сильно отличаться (подумайте о том, как вы внедряете IDisposable в разные классы, которые используют метод dispose). Однако клиентскому коду не нужно знать или заботиться о том, что является типом фактического объекта - код может просто получить доступ к нужным свойствам и методам через интерфейс.

Наследование часто рассматривается как «волшебный» ответ на многие проблемы кодирования, но также широко используется как средство, позволяющее избежать переписывания большего количества кода. Я не согласен с user492238, что все, что можно сделать с помощью интерфейсов, можно легко сделать с помощью наследования. Такой подход часто загоняет вас в угол. И, как замечает Джодрелл, множественное наследование не является особенностью .net (и, на мой взгляд, справедливо).

Когда вы обнаруживаете, что реализуете одно и то же поведение в нескольких (или во многих) не связанных между собой классах, рассмотрите возможность определения интерфейса, который предоставляет API для этого поведения. У вас может быть несколько классов: Person, Animal, Building и т. Д. Все из них могут требовать метод для вывода на печать. У вас также может быть метод, который принимает IPrintableObject в качестве параметра. В этом случае вы можете реализовать IPrintableObject в любом из классов, которые необходимо распечатать, предоставить код реализации в каждом из этих объектов и передать их клиентскому коду.

1 голос
/ 14 апреля 2011

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

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

Наличие совершенно не связанных между собой классов, реализующих один и тот же интерфейс, также позволяет вам писать методы, которые могут работать с разными классами в разных иерархиях (то есть без общего предка, кроме объекта), без необходимости принимать объект в качестве своего типа. Например, вы можете написать метод, который принимает IEnumerable и передает его List, Array и т. Д. Без интерфейсов или общего базового типа это было бы невозможно (за исключением приведения из объекта).

0 голосов
/ 26 октября 2014

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

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

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

0 голосов
/ 14 апреля 2011

Интерфейс - это контракт;это гарантия того, что указанные методы и свойства будут доступны.Он не обеспечивает реализацию, что отличает его от класса, который обеспечивает реализацию.

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

Интерфейсы почти семантически эквивалентны чисто абстрактным классам (классам, которые не обеспечивают любую реализацию).В c #, vb.net и других языках классы могут иметь несколько интерфейсов, но только один базовый класс.Поэтому для определенного преимущества интерфейсы перед классами (абстрактными или иными) заключаются в том, что вы можете реализовать несколько интерфейсов, но наследовать только от одного класса.

0 голосов
/ 14 апреля 2011

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

И существуют платформы (часто в сочетании с DI-контейнером), которые заставляют вас использовать интерфейсы.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...