Когда интерфейсы необходимы?

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

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

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

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

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

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

Это забавно. Вид этого парня взглядов, вероятно, что породило комментарии, такие как те центрирующиеся вокруг эпизода № 38.

StackOverflow

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

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

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

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

Если Вы хотите понять, когда использовать интерфейсы, и что является их использованием, я думаю, что необходимо смотреть на книгу: Главные Первые Шаблоны Desing .

Это - книга, которая действительно помогла мне понять то, что так прохладно об интерфейсах.

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

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

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

Для лучшего объяснения, попытайтесь смотреть на литературу по инверсия управления .

Интерфейсы помогают, Вы сохраняете зависимости от абстракций.

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

, По-моему, это - сущность хорошего дизайна кода.

"Парень выше говорит, что создает другой интерфейс для обработки нового участника (участников). Ничто не повреждается.

Не тот состав? Почему бы не использовать состав без интерфейсов? Более гибкий".

Вы, кажется, думаете о составе с точки зрения наследования, как в, "я наследую все эти возможности в этот объект сделать это задание". Это - плохой способ написать код. Это похоже на высказывание, "Я хочу создать небоскреб, таким образом, я узнаю, что каждое задание там должно знать, от того, как создать проекты на вниз к тому, как бедным основа и устанавливает освещение... "

Думают о составе вместо этого с точки зрения отдельных объектов, что каждый выполняет единственную задачу. Чтобы сделать сложное задание, я могу теперь полагаться на эти отдельные объекты для выполнения их отдельных задач. Это похоже на найм архитектора и команды конструкции для создания небоскреба. Я не должен знать в больших деталях, как каждый из них делает их задание, просто что они могут сделать это. В коде это означает вводить зависимости в объект выполнить сложные задачи вместо наследования.

Поэтому, где к интерфейсам вписываются? Они - контракт между отдельными объектами. Они позволяют Вам способность не заботиться о человеке, конкретных реализациях. Они позволяют Вам говорить общий язык с набором объектов, которые распределяют ту же ответственность, но могут на самом деле иметь другую реализацию. Интерфейс становится абстракцией к объекту, выполняющему задачу. Я не должен знать, как каждый парень с молотком работает, просто что он знает как к HitNail ().

, Когда Вы начинаете составлять сложную систему кода с большим количеством маленьких классов, которые имеют единственные обязанности, затем Вы скоро узнаете, что можно столкнуться с серьезными проблемами, если Вы полагаетесь слишком много на конкретную реализацию данного класса, и что класс начинает изменяться... Таким образом вместо того, чтобы полагаться на конкретную реализацию, мы создаем интерфейс - абстракция. И мы говорим, "Я не забочусь, как Вы делаете JobX, только что Вы делаете это".

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

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

Интерфейсы имеют много полезных ситуаций. Когда необходимо добавить определенное поведение к классу, который может быть найден через большое разнообразие классов, это - идеальное время для интерфейса. Хороший пример эти IDisposable интерфейс - у Вас есть некоторый ресурс, который, когда Вы сделаны, должен уйти своевременно. Действительно ли это - соединение с базой данных? Это - некоторый дескриптор окна? Не имеет значения.

Другой пример был бы, когда Вы действительно не делаете , знают, как он должен быть реализован, такие как интерфейс к объекту, который еще не существует. Возможно, объект должен быть предоставлен клиентом Вашей библиотеки или должен быть реализован совершенно другим модулем не под Вашим управлением. Можно в основном разработать контракт для методов, доступных на классе.

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

, Таким образом: Если Вам потребовали общей функциональности, это реализовано существенно по-другому, Интерфейс, в чем Вы нуждаетесь.

Согласно Википедия ,

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

Это - то, что делает интерфейсы настолько полезными.

"Парень выше говорит, что создает другой интерфейс для обработки нового участника (участников). Ничто не повреждается".

я просто предполагаю здесь, но это кажется, что этот парень происходит из старого школьного фона COM (я мог быть неправым, конечно!). Заставляет меня съежиться для размышления обо всем коде, я продолжил работать, где я видел вещи как это:

• IWidgetManager
• IWidgetManager2
• IWidgetManager3

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

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

Интерфейсы имеют большую часть смысла мне в контексте платформ МОК и внедрения зависимости. Мне нравится идея, что можно определить ряд поведений (методы) и "гарантировать" те поведения посредством реализации интерфейса. Теперь можно включить целые новые функции в существующую систему с единственным блоком и обновлением файла конфигурации.

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

• IComparable (ВЫ решаете, как Ваши объекты выдерживают сравнение друг с другом)
• IQueryable (LINQ кто-либо?)
• IDisposable (сохраняют Ваш using оператор удобный)

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

В прошлом некоторые утверждали, что каждый класс в системе должен иметь интерфейс, но это широко признается как излишнее. Теперь используются интерфейсы, в которых экземпляры классов могут изменяться как часть системной операции (для представления состояния): шаблоны GoF, такие как стратегия и команда, фиксируют это использование, и / или части системы необходимо заменить для тестирования (например, внедрение зависимостей). Если разработчики следуют методам разработки, основанной на тестировании, ключевые объекты инфраструктуры будут иметь интерфейсы. Это позволяет тестам «имитировать» эти объекты, чтобы проверить поток управления системой. Существует взаимосвязь между этим использованием интерфейса и принципом подстановки Лискова (один из принципов объектно-ориентированного проектирования)

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

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

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

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

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

Существует взаимосвязь между этим использованием интерфейса и принципом подстановки Лискова (один из принципов объектно-ориентированного проектирования)

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

Существует взаимосвязь между этим использованием интерфейса и принципом подстановки Лискова (один из принципов объектно-ориентированного проектирования)

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