Это хорошая практика для реализации двух методов Java 8 по умолчанию друг с другом?

Я проектирую интерфейс с двумя связанными методами, подобными этому:

public interface ThingComputer {
    default Thing computeFirstThing() {
        return computeAllThings().get(0);
    }

    default List<Thing> computeAllThings() {
        return ImmutableList.of(computeFirstThing());
    }
}

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

Есть ли у этого прецедент в широко используемом коде Java 8? Я знаю, что Haskell делает подобные вещи в некоторых классах типов ( Eqнапример).

Плюс в том, что мне приходится писать значительно меньше кода, чем если бы у меня было два абстрактных класса ( SingleThingComputerи MultipleThingComputer).

Недостатком является то, что пустая реализация компилируется, но взрывается во время выполнения с помощью a StackOverflowError. Можно обнаружить взаимную рекурсию с помощью a ThreadLocalи дать более приятную ошибку, но это добавляет издержки к не глючному коду.

TL; DR: не делай этого.

То, что вы показываете здесь, является хрупким кодом.

Интерфейс - это контракт. Он говорит «независимо от того, какой объект вы получаете, он может делать X и Y». Как написано, ваш интерфейс не делает ни X, ни Y, потому что он гарантированно вызовет переполнение стека.

Создание ошибки или подкласса указывает на серьезную ошибку, которая не должна быть обнаружена:

Ошибка - это подкласс Throwable, который указывает на серьезные проблемы, которые разумное приложение не должно пытаться обнаружить.

Кроме того, VirtualMachineError , родительский класс StackOverflowError , говорит следующее:

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

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

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

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

^{_{Источник: C ++ и Яма Отчаяния}}

Наличие интерфейса StackOverflowErrorпо умолчанию бросает разработчиков в Pit of Despair, и это плохая идея . Вместо этого подталкивайте разработчиков к Яме Успеха . Сделать это легко , чтобы правильно и без сбоев в JVM использовать интерфейс.

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

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