Когда нужны интерфейсы?

Question

(в контексте .NET для чего стоит)

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

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

Разве это не композиция? Почему бы не использовать композицию без интерфейсов? Более гибкий.

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

Я думаю о программном приложении как о графике. Полный график - наихудший случай, имеющий n (n-1) / 2. Это означает, что каждый класс говорит с каждым классом. Запутанная паутина. N-1 является лучшим, в котором их строгая иерархия общения. Добавление другого интерфейса просто для компенсации нового необходимого члена добавляет вершины к графу, что означает больше ребер и более сильную реализацию уравнения n (n-1) / 2. Композиция без интерфейсов больше похожа на миксин. Только выбранные классы используют определенные методы. Благодаря интерфейсу все классы вынуждены использовать члены, даже если они им не нужны. Подход "композиция / миксин" не добавляет новые ненужные края.

Answer 1

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

Answer 2

Похоже, ваш друг серьезно использовал интерфейсы.

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

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

Answer 3

Этот человек звучит так, как будто он неправильно понял концепцию программирования интерфейса. Это не относится к программированию с использованием только ключевого слова interface в .Net / Java или в классе, где есть только чисто виртуальные функции в C ++. Интерфейс, на который ссылаются в этом принципе, представляет собой высокоуровневую конструкцию, которая инкапсулирует низкое значение. Уровни системы. Как и в случае умножения, он заключает в себе идею добавления числа к себе определенного количества повторений. Но когда мы говорим 3 * 2, нам все равно, если 3 + 3, 2 + 2 + 2 или (2 + 2) + 2, где часть в скобках кэшируется. Пока мы получаем 6 от него.

На самом деле концепция интерфейсов может быть заполнена interface или abstract class или их комбинацией, как в случае со многими шаблонами GoF. Просто ключевое слово interface затуманивает воду.

Это смешно. Видение этого парня, вероятно, является тем, что породило комментарии, такие как те, которые сосредоточены вокруг эпизода StackOverflow # 38.

Answer 4

Я бы сослался на руководящие принципы проектирования .net по этому вопросу: http://msdn.microsoft.com/en-us/library/ms229013.aspx

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

Мое эмпирическое правило состоит в том, чтобы реализовать каждый интерфейс BCL, который имеет смысл, и добавлять мои собственные интерфейсы в мои проекты только тогда, когда они действительно предоставляют что-то очень ценное. Вместо IWidgetManager, IWidgetManager2 и т. Д ... Я бы предпочел иметь абстрактный класс WidgetManager и реализовывать конкретные методы по мере необходимости.

Answer 5

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