首先，我想说您所描述的问题不仅与 RMI 有关，而且与组件的任何类型的接口有关，包括纯 Java 接口，尽管在 RMI 的情况下，糟糕的设计可能会有额外的警告，例如性能。
不知道具体情况，只能看我的经历来猜测。这种不必要的接口复杂性通常与为组件定义的业务需求无效或不足有关。如果是这样的话，将来其他部门的人可能不得不经常修改界面，试图赶上新的功能，这通常是组件用户痛苦的原因。虽然随着时间的推移，界面的变化当然是自然的，但在这种情况下，它们可能会导致深度重新设计。
此外，过于复杂的接口通常意味着作者暴露了实现细节。不用说，这可能导致由于实现的演变、切换到不同的技术，甚至只是优化而导致不必要的接口更改。
最后但并非最不重要的一点是，为用户提供超出他们需要的更多内容是让他们使用甚至不打算使用甚至不存在的功能的直接方法。将来，用户可能会以意想不到的方式调用接口。它使组件的维护成为地狱。
总而言之，简单接口的关键参数是：组件的清晰业务定义、改进的实现灵活性、可维护性。请记住，所有这些利润对组件开发人员和用户都有好处。
你没有找错树，而是在不同的部门，你可能很难得到你想要的改变。你不可能赢得每一场战斗:-(
但是为你“打好仗”的道具。如果你有时间的话，我建议你向他们展示一个干净的界面版本。但除此之外，你可能只需要放手。
你将数据来完成你正在做的事情。我同意 unforgiven3 的观点——这是一场很好的战斗，而且你没有找错树——如果你现在提出更简洁的代码的建议，没有弹药，它可能会被置若罔闻，甚至更糟；可以开始一场“我的马比你的马大”的比赛——没有成效。
只是我的建议；
开始记录错误或任何其他与低效界面相关或指向低效界面的问题
开始记录代码审查，放入一个 wiki（公司认可的 wiki——现在不要惹麻烦），暂时记录一下——现在还不是通过判断的时候，你只是在收集数据。
当您从这 2 个中获得足够的数据时，请说明由于低效的设计决策而丢失或滥用的程序员生产力——当涉及成本时，很难争论。
希望能帮助到你。