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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

• Утешительные абстракции неизбежны. Но это полностью зависит от дизайнера. И btw "интерфейсы являются негерметичными абстракциями" означает, что они являются абстракциями.

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

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

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

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

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