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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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