RMI接口设计原则

Question

我目前正在开发一个RMI客户端，它将与RMI服务器(由我工作的公司的另一个部门开发)进行对话。另一个团队拥有接口，但IMO它过于复杂，有许多不同的类型来回传递，以及不必要的(IMO)复杂的异常层次结构。

我已经无数次表达过这样的担忧，即这种不必要的复杂性肯定会在以后我们进行集成时引发问题，但我并没有得到太多的关注。这将导致不必要的大量代码共享，再加上我们共享的每个不同的类都是一组需要关注的额外版本要求。

有没有人知道我可以用来支持我的论点的资源/论点。

或者，有没有人能让我相信我找错人了？

Answer 1

首先，我要说的是，您描述的问题不仅与RMI有关，还与组件的任何类型的接口有关，包括普通的Java接口，尽管在RMI的情况下，糟糕的设计可能会有额外的警告，例如性能。

我不知道细节，只能根据我的经验来猜测。接口的这种不必要的复杂性通常与为组件定义的无效或不足的业务需求有关。如果是这样的话，将来其他部门的人可能不得不频繁地修改界面，试图跟上新功能，这通常会给组件的用户带来痛苦。虽然随着时间的推移，界面的变化当然是自然的，但在这种情况下，它们可能会导致深度重新设计。

此外，过于复杂的接口通常意味着作者公开了实现细节。不用说，这可能会由于实现的演变而导致不必要的接口更改，切换到不同的技术，甚至只是优化。

最后但并非最不重要的一点是，给用户更多的东西是让他们使用甚至不打算使用或甚至不存在的功能的一种直接方法。将来，用户可能会以一种意想不到的方式调用界面。它使得组件的维护变得像地狱一样。

总而言之，简单接口的关键参数是:清晰的组件业务定义，改进的实现灵活性，可维护性。记住，所有这些利润对组件开发人员和用户都是有好处的。

Answer 2

你不是找错了人，而是在不同的部门，你可能很难得到你想要的改变。你不可能赢得每一场战斗：

而是你的道具，因为你“打得好”。如果你有时间的话，我建议你向他们展示一个干净版本的界面。但除此之外，你可能不得不让它过去。

Answer 3

你需要数据来完成你正在做的事情。我同意unforgiven3的观点--这是一场不错的比赛，而且你没有找错人--如果你现在提出一个更干净的代码的建议，如果没有证据，它可能会被置之不理，更糟糕的是；可能会开始一场类似“我的马比你的马更大”的比赛--不会有成效。

只是我的建议；

1. 开始记录错误，或者任何其他与低效的记录代码审查的interface
2. Start相关或指向的标签项目，放入一个维基(一个公司批准的维基--现在不要惹上麻烦)，现在只需要记录它--还不是时候做出判断，你只是在收集数据。

当你从这两个项目中获得足够的数据时，说明由于低效的设计决策而丢失或误用的程序员的生产力--当涉及成本时，很难争辩。

希望能有所帮助。