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?
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.