2つのJava 8のデフォルトメソッドを相互に実装するのは良い習慣ですか？

私はこれに似た2つの関連する方法でインターフェースを設計しています：

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

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

実装の約半分で計算されるのは1つだけですが、残りの半分ではさらに多くの計算が行われます。

これは、広く使用されているJava 8コードに先例がありますか？Haskellがいくつかのタイプクラスで同様のことを行うことは知っています（Eqたとえば）。

利点は、2つの抽象クラス（SingleThingComputerおよびMultipleThingComputer）を使用した場合よりも大幅に少ないコードを記述する必要があることです。

欠点は、空の実装がコンパイルされますが、実行時にStackOverflowError。を使用して相互再帰を検出しThreadLocal、より良いエラーを与えることは可能ですが、それにより、バグのないコードにオーバーヘッドが追加されます。

TL; DR：これをしないでください。

ここで示すのは、脆弱なコードです。

インターフェースは契約です。「取得するオブジェクトに関係なく、XとYを実行できます」と表示されます。書かれているとおり、インターフェイスはスタックオーバーフローを引き起こすことが保証されているため、 XもYも実行しません。

エラーまたはサブクラスをスローすると、キャッチすべきではない重大なエラーが示されます。

エラーはThrowableのサブクラスであり、合理的なアプリケーションがキャッチしようとしてはならない重大な問題を示します。

さらに、StackOverflowErrorの親クラスであるVirtualMachineErrorは次のように言います。

Java仮想マシンが壊れているか、動作を継続するために必要なリソースが不足していることを示すためにスローされます。

あなたのプログラムはJVMリソースに関係するべきではありません。それがJVMの仕事です。通常の操作の一部としてJVMエラーを引き起こすプログラムを作成するのは悪いことです。プログラムがクラッシュすることを保証するか、このインターフェースのユーザーに、関係のないエラーをトラップさせます。

「C＃言語設計委員会のメンバー」という名誉ある努力からエリック・リッパートを知っているかもしれません。彼は、人々を成功または失敗へと導く言語機能について語っています。これは言語機能や言語設計の一部ではありませんが、インターフェイスの実装やオブジェクトの使用に関しては、彼の主張は同様に有効です。

プリンセス・ブライドで、ウェストリーが目を覚まし、しわがれたアルビノと不吉な6本指の男、リューゲン伯爵と絶望の穴に閉じ込められているのを覚えていますか？絶望の穴の基本的な考え方は2つあります。第一に、それはピットであり、したがって、落ちやすいが、登るのは難しい仕事であること。第二に、それは絶望を引き起こす。したがって、名前。

^{_{ソース：C ++と絶望の穴}}

StackOverflowErrorデフォルトでインターフェースをスローすると、開発者は絶望のsに追い込まれますが、これは悪い考えです。代わりに、開発者をPit of Successにプッシュします それは作る簡単正しくJVMをクラッシュすることなく、あなたのインターフェースを使用します。

ここでは、メソッド間の委任は問題ありません。ただし、依存関係は一方向に進む必要があります。メソッドの委任を有向グラフのように考えるのが好きです。各メソッドはグラフ上のノードです。メソッドが別のメソッドを呼び出すたびに、呼び出し元のメソッドから呼び出されたメソッドにエッジを描画します。

グラフを描いて、それが周期的であることに気付いた場合、それはコードの匂いです。これは、開発者を絶望のpushingに追い込む可能性です。断固として禁止されるべきではなく、注意を払う必要があることに注意してください。再帰的アルゴリズムの呼び出しグラフには、特にサイクルがあります。それは問題ありません。それを文書化し、開発者に警告します。再帰的でない場合は、そのサイクルを中断してみてください。できない場合は、どの入力がスタックオーバーフローを引き起こす可能性があるかを調べ、それらを軽減するか、他に何も機能しない場合は最後のケースとして文書化します。