Преимущества реализации интерфейса

Каковы преимущества реализации интерфейса в С# 3.5?

Ответ 1

Вы сможете передать свой объект методу (или удовлетворить ограничение типа), которое ожидает интерфейс в качестве аргумента. С# не поддерживает " утиная печать." Просто написав методы, определенные интерфейсом, объект не будет автоматически "совместим" с типом интерфейса:

public void PrintCollection<T>(IEnumerable<T> collection) {
    foreach (var x in collection)
       Console.WriteLine(x);
}

Если List<T> не реализовал интерфейс IEnumerable<T>, вы не смогли бы передать его как аргумент методу PrintCollection (даже если он имел метод GetEnumerator).

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

Ответ 2

Основное преимущество - читаемость кода, удобство обслуживания кода и "семантика" кода.

Чтение кода:. Интерфейс представляет собой декларацию о намерениях. Он определяет способность вашего класса, что ваш класс способен делать. Если вы реализуете ISortable, вы четко заявляете, что ваш класс можно сортировать, то же самое для IRenderable или IConvertible.
Семантика кода: Предоставляя интерфейсы и реализуя их, вы активно разделяете понятия так же, как и HTML и CSS. Класс представляет собой конкретную реализацию "класса объектов" каким-либо образом представления реальности путем моделирования общих свойств объектов или концепций реальной жизни. Интерфейс определяет поведенческую модель, определение того, что может сделать объект. Разделение этих концепций позволяет лучше понять семантику вашего кода. Таким образом, некоторым методам может понадобиться экземпляр класса животных, в то время как другие могут принимать любой объект, который вы бросаете на них, если он поддерживает "ходьбу".
Поддерживаемость кода:. Интерфейсы помогают уменьшить сцепление и, следовательно, позволяют легко обмениваться реализациями для одной и той же концепции без воздействия на основной код. Вы можете легко изменить реализацию IMessage, указав новый класс, реализующий интерфейс. Сравните это, чтобы систематически заменить все ссылки от CMessage на CMyNewMessageClass.

Ответ 3

Это поможет, когда вы попытаетесь:

Unit test со Stubs/Mocks
Внедрение зависимостей
Решите голод в мире (хотя это недоказано!)

Доброта,

Дан

Ответ 4

Интерфейсы не обеспечивают фактического преимущества. Все, что может быть сделано с интерфейсом, может и должно выполняться с использованием других языковых конструкций. Множественное наследование часто цитируется как единственное РЕАЛЬНОЕ преимущество, получаемое от использования интерфейсов, но я могу сделать множественное наследование довольно легко и четко на С# - я делаю это каждый день. Изменение кода без "взлома" интерфейса - это самое глупое из всех оправданий... Это относится к конкретным классам так же, как к абстрактным классам или интерфейсам. Пока функциональная подпись не изменится, вы не нарушили интерфейс. Неважно, где это было объявлено. Просто поместить функциональный прототип в отдельный файл и называть его "я" впереди ничего не покупает, за исключением того, что у вас в два раза больше файлов-источников для поддержки. Предполагается, что интерфейс определен рано, а затем поддерживает контракт, это смешно. Методы интерфейса и их параметры изменяются все время, потому что все не известно заранее. Вот почему MicroSof прекратил использовать их давно. У них был IUnKnown, IUnknown2 и т.д. Это создало беспорядок.

Ответ 5

Основные преимущества интерфейсов в основном связаны с дизайном проекта.

Если вы используете интерфейс:

Потребитель интерфейса должен реализовать этот интерфейс.
Проектирование мостов.
Создание договора, чтобы пользователь соблюдал правила интерфейса.
Может взять только часть интерфейса (Object) из основного класса.
Даже класс является приватным, может получить объект интерфейса из этого
Тип множественного наследования стиля.
Не нужно было реализовывать, просто идти, если реализует это означает, что если вы хотите, чтобы вы могли реализовать другие мудрые, можете отказаться от него.
Код очистки.
Реализация, изменения которой зависят от класса, может идти вперед с интерфейсом.
Если у каждого класса есть отдельная реализация метода, лучше использовать интерфейсы. Например IEnumerable в коллекциях.

Согласно С# Architect, простым словом это контракт. Потребитель должен придерживаться этого.

Ответ 6

Интерфейс определяет контракт (вещи, которые может сделать объект), а конкретный класс (или структура) определяет конкретное поведение.

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

Ответ 7

Если вы работаете в огромном коммерческом доме программного обеспечения - вы МОЖЕТЕ рассмотреть вопрос о судебном использовании интерфейсов. В противном случае вам следует держаться подальше от них. То же самое для многопоточности. Если я увижу еще одно приложение script -kiddie, которое порождает 20 потоков, чтобы написать "Hello World", я собираюсь урод. Многопоточность должна быть полностью зарезервирована для приложений, которые этого требуют, как правило, в среде многопроцессорной обработки. 90% времени причиняет больше вреда, чем пользы. И не беспокойтесь о комментариях по теме highjack/off-topic. Мне все равно. Я делал это дольше, чем большинство из вас были живы. Ранг имеет свои привилегии.

Ответ 8

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

Ответ 9

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

Ответ 10

Насколько я понимаю, интерфейсы наиболее полезны в этих случаях:

Более чистое разделение труда среди программистов. Ведущий программист пишет интерфейс, а младший программист пишет о его реализации. Это имеет для меня смысл. Ведущий программист мог писать псевдокод вместо интерфейса.
Некоторая конкретная ситуация, когда вам нужны 2 или более разных реализаций одного и того же класса, например, интерфейс животного и классы тигра и льва, которые его используют. И даже здесь это не имеет большого значения, потому что львы и тигры имеют общие черты. Абстрактный класс был бы лучше, потому что, если вы используете интерфейс, вы должны писать общие функции в отдельных классах, что приводит к дублированию кода, что плохо.
Вы пишете библиотеку и хотите, чтобы она была модифицируемой пользователями. Таким образом, вы пишете интерфейс и его реализацию класса. У пользователя вашей библиотеки все еще есть возможность написать свой собственный класс реализации, который может использовать разные технологии/алгоритмы, которые достигают одного и того же результата, но, возможно, быстрее, например. Это также является причиной того, что мы встречаем так много интерфейсов в libs, которые мы используем, но редко чувствуем необходимость писать наши собственные интерфейсы. Потому что мы не пишем библиотеки.