プロジェクトのバグを修正する必要がありますが、根本的な原因は、設計上の問題により、インターフェイスのすべての実装に広がった多くの回避策の影響であることが判明しました。そのインターフェースをリファクタリングしたいのですが、すべての実装を変更する時間がないため、今はできません。したがって、私のアイデアは、このインターフェイスにデフォルト メソッドを追加し、それを 1 つの実装だけに実装して (設計上の問題を部分的に修正)、次のスプリントで大きなリファクタリングを行うことです。このリファクタリングは、このインターフェースのすべてのメソッドをより単純で意味のあるものに置き換えることです。これらの新しいメソッドの 1 つは、質問の対象となるデフォルトのメソッドです。
しかし、実際には、このメソッドに必要な実装はありません。これは、正しい方向に向かう一時的な解決策にすぎません。
UnsupportedOperationException をスローするデフォルト メソッドを (もちろんインターフェイスで) 実装することは理にかなっていますか?
デフォルト メソッドの背後にある全体的な考え方は、既存の実装を自動的に壊すことなく、インターフェイスにメソッドを追加できるようにすることです。それがあなたが提案しているように見えるので、それはそれが行く限り理にかなっています.
しかし、コメントであなたは次のように述べました：
バグを修正する必要がある実装クラスでそれをオーバーライドし、意味をなさない前のメソッドの代わりにこの新しいメソッドを呼び出します。
インターフェイスの任意のインスタンスで新しいメソッドを呼び出す場合は、適切な処理が行われることを確信する必要があります。そのような呼び出しが、常にスローする提案されたデフォルトの実装によって提供される可能性がある場合UnsupportedOperationException(そしてそれが望ましくないと仮定すると)、おそらくそのような信頼を正当化することはできません。
新しいメソッドが 1 つの特定の実装クラスのインスタンスでのみ呼び出されるという正当な確信がある場合は、インターフェイスの使用方法に非常に奇妙な点があるか、実際にインターフェイスをまったく変更する必要がないかのいずれかです。 . つまり、使用している実装がわかっている場合は、インターフェイスを変更せずに、そのクラスだけに新しいメソッドを追加できます。