RMI interface design principles

Question

Im currently working on an RMI client that will talk to an RMI server (developed by a different division of the company I work for). The other team own the interface, but IMO it's overly complex, with many different types being passed backwards and forwards, as well as an unnecessarily (IMO) complex exception hierarchy.

I've expressed concern numerous times that this is the sort of unnecessary complexity is a sure fire source of problems later on when we come to integrate, but Im not getting much traction. IMO it will lead to an unnecessarily large amount of code sharing, plus every single different class we share is an extra set of versioning requirements that need to be watched.

Does anyone know of any resources/arguments that I can use to bolster my argument.

Alternatively can anyone convince me that I'm barking up the wrong tree?

Answer 1

Your not barking up the wrong tree, but being in a different division, you might have a hard time getting the changes you want. You can't win every battle :-(

But props to you for "fighting the good fight". I'd suggest you present them with a cleaned-up version of the interface, if you have the time to do it. But other than that, you might just have to let it go.

Answer 2

You'll data to accomplish what you're doing. I agree with unforgiven3 -- it's a good fight, and you're not barking up the wrong tree -- if you present the suggestion of a cleaner code right now, without ammunition, it could fall on deaf ears, and worse; could start a "my horse is bigger than your horse" kind of contest -- not productive.

Just my suggestion;

1. Start documenting the bugs, or any other ticket item which relates or points to the inefficient interface

2. Start documenting the code reviews, put in a wiki (a company sanctioned wiki -- don't get into trouble now), just document it for now -- it's not yet time to pass judgement, you're just gathering data.

When you've got enough data from these 2, make a case on programmer productivity that is being lost or misused because of inefficient design decisions -- it's very difficult to argue when cost is involved.

hope it helps.

Answer 3

First of all, I would say that the problem you described pertains not only to RMI but to any kind of interface of a component, including plain Java interface, although in case of RMI a bad design may have additional caveats, e.g. performance.

Not knowing the details, I can only guess by looking at my experience. Such an unnecessary complexity of an interface is often related to invalid or insufficient business requirements defined for the component. If that's the case, in future the guys at the other division will probably have to frequently modify the interface, trying to catch up with new features, which is usually a cause of pain for the users of the component. Although changes of the interface are of course natural over time, in this case they may result in a deep redesign.

Furthermore, an overly complex interface usually means that the author exposes implementation details. Needless to say, this can lead to unnecessary interface changes due to the evolution of the implementation, switching to a different technology, or even optimization only.

Last but not least, giving the users more than they need is a straight way to letting them use functionalities not even intended to be used, or even exist. In future, it may turn out that the users invoke the interface in an unexpected way. It makes the maintenance of the component a hell.

To wrap it up, the key arguments for a simple interface are: clear business definition of a component, improved flexibility of the implementation, maintainability. And remember, all those profits are good for both the component developers and the users.