Интерфейсы (интерфейс / абстрактный класс) не являются абстракциями?

Question

В последнее время я читаю посты, в которых говорится о предполагаемом неправильном представлении, что интерфейсы - это абстракции. Один такой пост http://blog.ploeh.dk/2010/12/02/InterfacesAreNotAbstractions.aspx

Я немного растерялся. Если у меня нет интерфейсов (интерфейс / абстрактный класс), как я могу внедрить свои зависимости и высмеять их?

Кроме того, я слышал, что люди говорят о том, что не используют интерфейсы, в которых есть только один разработчик. Мне нравится этот блог здесь - http://simpleprogrammer.com/2010/11/02/back-to-basics-what-is-an-interface/

Теперь все это, разве это не нарушает принцип - Программа для интерфейса, а не для реализации?

Answer 1

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

Когда мы говорим «интерфейс» в терминах программирования для интерфейса. Этот вид интерфейса означает внешние методы и свойства класса. Это не обязательно должен быть языковой интерфейс. (Интерфейс ключевого слова.)

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

Answer 2

Я бы сказал, что я не согласен со многими пунктами в связанных статьях:

• интерфейсы являются контрактами.Контракт состоит из двух частей - сигнатура метода (чисто синтаксическая) и документация .

• интерфейсы являются абстракциями,Я не мог видеть пример нарушения LSP.Пример IRectangle не совсем хороший.То же самое можно сказать о Set extends Collection, где добавление дубликатов запрещено.Если вы получили Collection, вы можете быть удивлены, что он запрещает дубликаты.Для интерфейсов Collection это делается путем документирования того, что разработчики могут добавлять ограничения

• Утечка абстракций неизбежна.Но это полностью зависит от дизайнера.А между прочим, «интерфейсы - это утечка абстракций» означает, что они являются абстракциями.

• Парни, похоже, пропустили «подвергание» юнит-тестированию.Ложные реализации - очень веская причина для использования интерфейса (хотя вы можете и лживые конкретные классы).

• Очень хороший пример из нашего текущего проекта - изначально у нас только одна реализация DAO- один берет материал из базы данных.Но позже мы переключили некоторые операции на специализированную поисковую систему.Мы добавляем еще одну реализацию DAO, и мы идем.Таким образом, имея интерфейс с одной реализацией , первоначально окупился.

• Кстати, изначально SortedSet имел только одну реализацию в JDK - TreeSet.Теперь у него есть два.И многое другое из внешних библиотек.

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

Все это говорит о том, что вам не нужен интерфейс для всего.Но это зависит от конкретного случая.Я, например, не использую интерфейсы для вспомогательных классов.И действительным пунктом статей является то, что «программирование интерфейса» не обязательно включает ключевое слово interface.«Открытый интерфейс» класса - это (теоретически) набор его открытых методов.

Answer 3

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

Вот пример использования, который у меня часто встречается, когда наличие только одного разработчика (на мой взгляд) совершенно нормально: у вас есть компонент Swing, скажем, CarComparisonResultsPanel, который позволяет пользователю увидеть результаты сравнения между машины. Как пользователь панели, я бы предпочел иметь интерфейс CarComparisonResult с getCarSimilarities() и getCarDifferences(), чем реализацию JPanel, которая реализует эти методы, а также десятки других.

РЕДАКТИРОВАТЬ: Чтобы немного прояснить мою точку зрения «не переусердствуй», приведу несколько примеров переопределения: интерфейсы для фабрик, построителей, вспомогательных / служебных классов, компоненты графического интерфейса, которые не добавляют соответствующие открытые методы их родителю, ...

Answer 4

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

Может случиться так, что при разработке интерфейса вы поймете, что вам не нужно делать его интерфейсом, и для тестирования будет достаточно перегрузки и наследования.Как упоминалось в первой статье, если вы последовательно получаете соотношение 1: 1 между объектами и интерфейсами без цели, кроме «Я программирую на интерфейсах», вы просто вносите беспорядок в свой код.

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