Должны ли вы всегда кодировать для интерфейса?

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

Это популярный шаблон среди разработчиков Java:

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

Это хорошо известная и довольно хорошая закономерность. Преимущества хорошо описаны в Интернете, например, Сильвия Фрончак цитирует известные шаблоны дизайна:

Клиенты остаются в неведении о конкретных типах объектов, которые они используют, до тех пор, пока объекты соответствуют интерфейсу, который ожидают клиенты.

Клиенты остаются в неведении о классах, которые реализуют эти объекты. Клиенты знают только об абстрактных классах, определяющих интерфейс. “

источники: https://blog.ndepend.com/programming-interface-simple-explanation/ , https://en.wikipedia.org/wiki/Design_Patterns

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

Интерфейсы делают ваш код менее хрупким. Если реализации изменятся, ваш код все равно будет работать — до тех пор, пока интерфейс не изменится.

Однако возникает насущный вопрос, когда следует использовать программирование по шаблону интерфейса. Есть несколько интересных ответов на этот вопрос:

Сильвия Фрончак подчеркивает необходимость поиска баланса, когда дело доходит до использования шаблона:

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

Филип Браун оказывает некоторое давление на то, чтобы иметь много детских классов:

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

Иво Куманс указывает, что это руководство:

Если вы будете следовать руководству “программировать для интерфейса, а не для реализации”, вы нарушите принцип KISS. Но, создав кучу простых классов, которые повторяют какой-то код или действия, вы нарушили бы принцип DRY. источник:

Тор Ховланд перечисляет ситуации, когда кодирование с использованием интерфейса является хорошим, в основном:

Когда они повышают ценность, они полезны. Я только говорю, что интерфейсы, которые отражают одну и только одну реализацию класса, являются пустой тратой времени. источник: https://blog.hovland.xyz/2017-04-22-stop-overusing-interfaces/

Йерун Ванневель указывает также на общее правило, которое он считает хорошим:

(…) вы должны определить свою программу с учетом минимально возможной абстракции без потери функциональности источник: (…) вы должны определить свою программу с учетом минимально возможной абстракции без потери функциональности

Если дело дойдет до конфликта с КИССОМ и ЯГНИ Дэниелсон отмечает, что конфликта может даже не существовать:

Проще (KISS) программировать на основе общего интерфейса, чем на основе конкретной реализации. Если вам не нужна конкретная реализация, вам следует использовать источник generic interface (YAGNI): https://stackoverflow.com/a/65874938/38940

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

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

Однако это относится не ко всем проектам, случаям и языкам. Давайте возьмем пример из моего вопроса StackOverflow. Если у меня есть короткий фрагмент кода, который ничего не делает, кроме как использует временную переменную. Должен ли я использовать:

Map langMap = new HashMap<>();

или

HashMap langMap = new HashMap<>();

?

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

Но это предполагает, что я следую программированию в соответствии с шаблоном интерфейса в любой ситуации. И вопрос поста в том, действительно ли я должен это делать?

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

На самом деле, если мы думаем о других шаблонах, мы не всегда их используем. Мы не пишем фабричные методы, конструкторы, Фасады и прокси-серверы для каждого фрагмента кода. Мы пишем их, когда это важно для качества кода.

Как и во всех шаблонах, их использование без причины также приводит к некоторым выводам:

1) Человек, который их использует, на самом деле ничего о них не знает 2) Как новый уровень абстракции это увеличивает ненужную сложность кода

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

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

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

Но также, если вы сознательно решите не использовать шаблон, потому что в конкретной ситуации нет никаких преимуществ, это тоже прекрасно.

До тех пор, пока вы осознаете, что делаете, оба способа хороши.

Есть ли что-нибудь, что я пропустил по этому вопросу? Вы с чем-то категорически не согласны? У вас другое мнение? Напишите комментарий! Также помните о Кодексе поведения ( https://dev.to/code-of-conduct )!

Оригинал: “https://dev.to/tomaszs2/should-you-always-code-against-an-interface-4noi”