我需要修复我的项目中的一个错误，但事实证明，根本原因是由于设计问题而对接口的所有实现传播的许多变通方法的影响。我想重构那个接口，但我现在做不到，因为我没有时间更改所有实现。所以我的想法是在这个接口中添加一个默认方法，并且只在一个实现中实现它（部分修复设计问题），然后在下一个 sprint 中进行大重构。这种重构是为了将这个接口中的所有方法替换为更简单、更有意义的方法。其中一种新方法是问题所在的默认方法。
但实际上这种方法不需要实现，它只是一个走向正确方向的临时解决方案。
实现抛出 UnsupportedOperationException 的默认方法（当然是在接口中）有意义吗？
默认方法背后的整个想法是在不自动破坏现有实现的情况下向接口添加方法。看起来这就是你打算做的，所以就它而言，这是有道理的。
但在评论中你说：
我将在需要修复错误的实现类中覆盖它，然后调用这个新方法而不是以前没有意义的方法。
如果您要在接口的任何实例上调用新方法，那么您需要确信它会做一些适当的事情。如果您提出的总是抛出的默认实现有可能提供这样的调用UnsupportedOperationException（并且假设这是不可取的），那么这可能不能证明这种信心是合理的。
如果您确实有理由相信新方法只会在一个特定实现类的实例上被调用，那么要么您使用接口的方式有些奇怪，要么您实际上根本不需要更改接口. 也就是说，如果您知道您正在使用什么实现，您可以单独将新方法添加到该类，而无需更改接口。