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

Question

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

Answer 1

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

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

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

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

Answer 2

Это поможет при попытке: тест единицы

• заглушками/Mocks
• Реализовать Dependency Injection
• Solve мировой голод

Kindness, (хотя это не доказано!)

Дэн

Answer 3

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

Answer 8

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

Answer 9

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

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

1. Потребитель интерфейс должен реализовывать этот интерфейс.
2. Дизайн моста паттернов.
3. Создание договора, чтобы пользователь соблюдал правила интерфейса.
4. Может принимать только часть интерфейса (Object) от основного класса.
5. Даже класс является частным, может получить объект интерфейса от этого
6. Множественный тип наследования типа.
7. Не нужно было реализовывать, просто идти, если реализует, что означает, что если вы хотите, чтобы вы могли реализовать другие мудрые, можете его отбросить.
8. Очистительный код.
9. Реализация, которая зависит от класса, может идти вперед с интерфейсом.
10. Если у каждого класса есть отдельная реализация метода, лучше использовать интерфейсы. Например, IEnumerable в коллекциях.

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

Answer 10

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

1. Чистое разделение труда среди программистов. Ведущий программист пишет интерфейс, а младший программист пишет о его реализации. Это имеет для меня смысл. Ведущий программист мог писать псевдокод вместо интерфейса.

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

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