1

Я понимаю интерфейс как контракт, который может быть применен к классам, которые иначе не имели бы ничего общего (например: Comparable in Java). Однако, в какой ситуации (-ых) у вас будет рефлекс добавления интерфейса на этапе проектирования?Дизайн приложения - Когда должны использоваться интерфейсы?

ответ

5

«Я понимаю интерфейс как контракт, который может быть применен к классам, которые в противном случае не имели бы ничего общего» - это, вероятно, не способ думать о том, что такое Интерфейс.

Интерфейс описывает поведение, а реализация интерфейса означает, что класс входит в контракт для доставки этого поведения.

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

public void DoSomething(IQuack quacker) 
{ 
    // ... 
} 
5

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

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

+1

+1 уменьшенное сцепление. Одним из результатов этого является возможность модульных тестов для издевательства объектов за пределами тестируемого устройства. –

+0

Простые модульные тесты являются лишь побочным эффектом уменьшенной связи - это просто делает код намного более гибким. – Arafangion

+1

Правильно - это «один из последствий этого». –

2

Если вы разрабатываете продукт, и знаете, что продукт будет взаимодействовать с типом устройства, сервисом и т. Д., Но не обязательно, вы можете использовать интерфейс для продвижения вперед с общей архитектурой, ПРЕДОСТАВЛЯЕМЫЙ, достаточно об этих типах устройств для написания интерфейса, который может быть успешно использован любым данным устройством такого типа. Конечно, если вы находитесь на этапе проектирования, вам лучше иметь это знание. Нередко можно создавать проекты высокого уровня, используя только декларации интерфейса. Я не говорю, что это хорошо или плохо, но, похоже, это довольно распространенная практика тех, кто использует программное обеспечение (например, Rose и т. Д.) Для создания скелета из UML.

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

Третье использование интерфейсов заключается в сокращении дублированного кода. Это, вероятно, единственное место, где люди когда-либо увлекаются использованием интерфейса, и если бы это было не так, мне было бы удобно говорить, не спрашивая: «Должен ли это быть интерфейс?» но «Может ли это быть интерфейсом?».

+2

«Фаза проектирования»? Вы, кажется, предполагаете, что разработка программного обеспечения осуществляется в серии отдельных этапов? Вы также, кажется, предполагаете, что знаете все, с чем продукт собирается взаимодействовать заранее? – Arafangion

+0

«Фаза проектирования», как на этапе, который выполняет сбор требований, а также «Фаза требований/анализа». http://infolab.stanford.edu/~burback/watersluice/node2.html – Nick

+0

Что касается знания всего, что продукт собирается взаимодействовать заранее, я не уверен, что понимаю комментарий. Если вы имеете в виду, я предполагаю, что знаю все «типы» «вещей», с которыми я буду взаимодействовать, да. Если вы имеете в виду, я предполагаю, что знаю точную модель/rev/etc. «вещей», то нет. Для этого нужны интерфейсы. Но вы все еще не можете просто написать интерфейс для «вещи», не выполняя маленькую домашнюю работу. – Nick