This is based around the idea that RPC calls are usually to bridge scripting calls added in the client/designer to their gateway implementations.
Define some RPC interfaces in common:
interface FooFunctions {
void foo1();
String foo2();
}
interface BarFunctions {
void bar1();
String bar2();
}
In the gateway (client/designer too, but they just invoke RPC using the above interface), you presumably have some script modules:
class FooScriptModule implements FooFunctions {
@Override
public void foo1() {
System.out.println("foo1");
}
@Override
public String foo2() {
return "foo2";
}
}
class BarScriptModule implements BarFunctions {
@Override
public void bar1() {
System.out.println("bar1");
}
@Override
public String bar2() {
return "bar2";
}
}
Now you need an RPC handler, but you don’t want to clutter it… let’s get tricky.
public interface FooFunctionsMixin extends FooFunctions {
FooScriptModule fooScriptModule();
default void foo1() {
fooScriptModule().foo1();
}
default String foo2() {
return fooScriptModule().foo2();
}
}
public interface BarFunctionsMixin extends BarFunctions {
BarScriptModule barScriptModule();
default void bar1() {
barScriptModule().bar1();
}
default String bar2() {
return barScriptModule().bar2();
}
}
public class MyRpcHandler implements FooFunctionsMixin, BarFunctionsMixin {
private final GatewayContext context;
private final ClientReqSession session;
private final FooScriptModule fooScriptModule;
private final BarScriptModule barScriptModule;
public MyRpcHandler(
GatewayContext context,
ClientReqSession session) {
this.context = context;
this.session = session;
// Create your script modules, or maybe pass them in as
// parameters instead. Whatever works for your application.
fooScriptModule = new FooScriptModule();
barScriptModule = new BarScriptModule();
}
@Override
public FooScriptModule fooScriptModule() {
return fooScriptModule;
}
@Override
public BarScriptModule barScriptModule() {
return barScriptModule;
}
}
In your case, you might have a script module and “mixin” for each of the 24 scripts, if that makes sense for you. The RPC handler will just have 24 xyzScriptModule()
methods and implement 24 “mixin” interfaces. Whatever methods belong to each of those 24 scripts go on the other classes we defined here.
Caveat: I haven’t actually verified this mixin shenanigans works with the RPC mechanism. If it doesn’t, you’d just forgo the mixin interfaces and have 100+ calls on your RPC handler that delegate to the appropriate script module.