Чи є гарною практикою реалізація двох методів за замовчуванням 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).

Мінус полягає в тому, що порожня реалізація компілюється, але під час виконання програми підіймається StackOverflowError. Можна виявити взаємну рекурсію за допомогою a ThreadLocalі дати приємнішу помилку, але це додасть накладних витрат на невідповідний код.

TL; DR: не роби цього.

Що ви тут показуєте, це крихкий код.

Інтерфейс - це договір. У ньому написано "незалежно від того, який предмет ви отримаєте, він може робити X і Y". Як написано, ваш інтерфейс не робить ні X, ні Y, оскільки це гарантовано може викликати переповнення стека.

Викидання помилки або підкласу вказує на серйозну помилку, яку не слід сприймати:

Помилка - це підклас Throwable, який вказує на серйозні проблеми, які розумна програма не повинна намагатися наздогнати.

Крім того, VirtualMachineError , батьківський клас StackOverflowError , говорить про це:

Викинуто, щоб вказати, що віртуальна машина Java зламана або не вистачає ресурсів, необхідних для її подальшої роботи.

Ваша програма не повинна стосуватися ресурсів JVM . Така робота СП. Зробити програму, яка викликає помилку JVM як частину звичайної роботи, погано. Це або гарантує, що ваша програма вийде з ладу, або змушує користувачів цього інтерфейсу відловлювати помилки, з якими вона не повинна стосуватися.

Ви можете знати Еріка Ліпперта з таких зусиль, як emeritus "член комітету з розробки мови C #". Він розповідає про мовні особливості, що підштовхують людей до успіху чи невдачі: хоча це не мовна особливість або частина мовного дизайну, його точка настільки ж справедлива, що стосується впровадження інтерфейсів або використання об'єктів.

Ви пам’ятаєте в «Принцесі нареченій», коли Вестлі прокидається і опиняється замкненим у «Ямі Відчаю» із хрипким альбіносом та зловісною шестигранною людиною, графом Ругеном? Принципова ідея ями відчаю двояка. По-перше, що це яма, і тому легко потрапити в цю, але важку роботу з якої вилізти. І друге, що це викликає відчай. Звідси і назва.

^{_{Джерело: C ++ та "Пітне розпач"}}

Якщо викинути інтерфейс StackOverflowErrorза замовчуванням, штовхає розробників у яму розпачу, і це погана ідея . Натомість підштовхуйте розробників до « Ями Успіху» . Зробіть простий у використанні інтерфейс правильно та без збоїв JVM.

Делегація між методами тут добре. Однак залежність повинна йти в один бік. Мені подобається думати про делегування методу, як спрямований графік . Кожен метод - це вузол на графіку. Кожен раз, коли метод викликає інший метод, намалюйте край від методу виклику до методу, який називається.

Якщо ви намалюєте графік і помітите, що він циклічний, це кодовий запах. Це потенціал для підштовхування розробників до Ями розпачу. Зауважте, що категорично заборонено це не слід, лише потрібно обережно . Рекурсивні алгоритми конкретно матимуть цикли в графіку викликів: це нормально. Задокументуйте це та попередити розробників. Якщо це не рекурсивно, спробуйте перервати цей цикл. Якщо ви не можете, з’ясуйте, які вхідні дані можуть спричинити переповнення стека, або пом'якшуйте їх, або документуйте це як останній випадок, якщо більше нічого не вийде.