Интерфейсы vs Public Class Members

Question

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

Хотелось бы услышать ваше мнение об интерфейсах. Когда вы используете их и для каких целей?

спасибо.

Answer 1

В первую очередь я использую интерфейсы для IoC, чтобы включить модульное тестирование.

Answer 2

Интерфейсы - это мощный инструмент для абстракции. С их помощью вы можете более свободно подставлять (например) тестовые классы и тем самым отделять свой код. Они также способ сократить объем вашего кода; вам, вероятно, не нужен полный набор функций данного класса в определенном месте - какие именно функции вам нужны? Это ориентированный на клиента способ мышления об интерфейсах.

Answer 3

Единичные испытания.

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

Answer 4

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

Answer 5

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

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

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

Answer 6

Мне нравятся интерфейсы:
* определить контракт между частями/модулями/подсистемами или 3-ем партийной системой
* при наличии заменяемого состояние или алгоритмы (состояние/стратегии) ​​

Answer 7

Это все ожидают и подготовок для изменения.

Один подход, который используется некоторыми (и я не обязательно защищаю его) - это создание IThing и ThingFactory.

Весь код будет ссылаться на IThing (вместо ConcreteThing). Все создание объекта может быть выполнено с помощью метода Factory.

ThingFactory.CreateThing (некоторые параметры).

Итак, сегодня у нас есть только AmericanConcreteThing.И возможно, что нам никогда не понадобится другое. Однако, если опыт научил меня чему-то, мы всегда будем нуждаться в другом.

Вам может не понадобиться EuropeanThing, но TexasAmericanThing - это отличная возможность.

Таким образом, для того, чтобы свести к минимуму воздействие на мой код, я могу изменить созидательные линию:

ThingFactory.CreateThing (счета) и создать свой класс TexasAmericanThing: IThing.

Другой, чем строительство класса, единственное изменение в ThingFactory, что потребует изменений от

public static IThing CreateThing(Account a) 
{ 
    return new AmericanThing(); 
} 

to 

public static IThing CreateThing(Account a) 
{ 
    if (a.State == State.TEXAS) return new TexasAmericanThing(); 
    return new AmericanThing(); 
} 

Answer 8

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

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

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