Aligning types of generically created model and service that consumes model

Okay, this is a complex problem, so I'm gonna try my best to distill it to a simple format.

The overarching goal of what I'm trying to do is to create an interface and a few implementations of said interface. The interface has a single method with a void return and a single argument.

The single argument is a POJO that has subclasses. Each implementation of the interface consumes a version of the POJO: some fields of the POJO are shared by all implementations, other fields are specific to the implementation.

The current architecture of this that I have going looks like this:

The POJOs

public abstract class ExecutionContext {
    String name;
}

public class FirstExecutionContext extends ExecutionContext {
    int id;
}

public class SecondExecutionContext extends ExecutionContext {
    String description;
}

The interface and implementations

public interface Executor<T extends ExecutionContext> {
    void execute(T context);
}

public interface FirstExecutor implements Executor<FirstExecutionContext> {
    void execute(FirstExecutionContext context) { ... }
}

public interface SecondExecutor implements Executor<SecondExecutionContext> {
    void execute(SecondExecutionContext context) { ... }
}

So, question one: does this structure make sense?

The next problem comes when I try to actually call this method. The problem here is that I need to generically create both the Executor and the Context, and I cannot for the life of me figure out how to architect this to chain the calls without errors of some sort.

I started with a calling class that looks something like this (just ignore the if conditional logic, seemed simpler than setting up an enum)

public class ExecutorWorker {
    public void buildAndCallExecutor(String name, int id, String description, String type) {
        if (type.equals("FIRST")) {
            FirstExecutor executor = new FirstExecutor();
            FirstExecutionContext executionContext = new FirstExecutionContext();
            executionContext.setName(name);
            executionContext.setId(id);

            executor.execute(executionContext);
        } else if (type.equals("SECOND")) {
            SecondExecutor executor = new SecondExecutor();
            SecondExecutionContext executionContext = new SecondExecutionContext();
            executionContext.setName(name);
            executionContext.setDescription(description);

            executor.execute(executionContext);
        }
    }
}

Now this works, but completely ignores the abstraction of the interfaces and ends up with a fair amount of duplicated code (especially as the construction of ExecutionContext becomes more complex). However, this is where I've hit a wall: how can I refactor this code to be more generic?

In particular, the issue I consistently run into is generically constructing both the ExecutionContext and the Executor, then having them get along. Here's an attempt with wildcards (just focusing on refactoring the Executor for now):

public class ExecutorWorker {
    public void buildAndCallExecutor(String name, int id, String description, String type) {
        Executor<? extends ExecutionContext> executor;
        ExecutionContext executionContext;

        if (type.equals("FIRST")) {
            executor = new FirstExecutor();
            FirstExecutionContext firstExecutionContext = new FirstExecutionContext();
            firstExecutionContext.setName(name);
            firstExecutionContext.setId(id);
        } else if (type.equals("SECOND")) {
            executor = new SecondExecutor();
            SecondExecutionContext secondExecutionContext = new SecondExecutionContext();
            secondExecutionContext.setName(name);
            secondExecutionContext.setDescription(description);
        }

        executor.execute(executionContext); // compile error: required: capture of ? extends ExecutionContext, provided: ExecutionContext
    }
}

I also tried this with generics, but also to no avail:

public class ExecutorWorker {
    public <T extends ExecutionContext> void buildAndCallExecutor(String name, int id, String description, String type) {
        Executor<T> executor;
        T executionContext;

        if (type.equals("FIRST")) {
            executor = new FirstExecutor(); // compile error: required type: Executor<T>, provided: FirstExecutor
            FirstExecutionContext firstExecutionContext = new FirstExecutionContext();
            firstExecutionContext.setName(name);
            firstExecutionContext.setId(id);
        } else if (type.equals("SECOND")) {
            executor = new SecondExecutor(); // compile error: required type: Executor<T>, provided: SecondExecutor
            SecondExecutionContext secondExecutionContext = new SecondExecutionContext();
            secondExecutionContext.setName(name);
            secondExecutionContext.setDescription(description);
        }

        executor.execute(executionContext); 
    }
}

The fundamental issue with each approach is that I can't figure out how to align the generics between the Executor and the Context - for some subtype of ExecutionContext, I want to construct an instance of that subtype and instantiate a subtype of Executor that consumes that subtype. How can I align these two actions? Or am I going about this all wrong?

You could use a reImplementation of Executor that allows to call all setters from executor, for example using an interface that implements those setters

public interface setter<T extends ExecutionContext> {
    void execute(T context);
    public T setDescritpion(String description);
    public T setId(int id);
}

public abstract class ExecutionContext implements setter{
    String name;
}

Now you will be foced to implement the missing methods in the non-abstract childs, if a child doesent have a particular field just do nothing in the specific setter.

Then I think a factory would be nice so you can get the context you need at runtime

public class ExecutionContextFactory {
    public static ExecutionContext getExecutionContext(TypeEnum type) {
        switch (type){
            case FIRST: return new FirstExecutionContext ();
            case SECOND: return new SecondExecutionContext ();
        }
    }
}

and a nearly identical one for the executors.

Now you can simply do

public void buildAndCallExecutor(String name, int id, String description, String type) {
        ExecutorFactory
            .getExecutor(type).execute(
                 ExecutionContextFactory
                    .getExecutionContext(type)
                    .setName(name)
                    .setDescription(description)
                    .setId(id)
            )
}

I think it should work, not tested though.

Another thing you could do is reflection, you could implement in the superclasses some utility methods that allows to acces fields and methods and set those fields using simply the name of the Fields you want. There are many possibilities, it really depends on the application context

> „…buildAndCallExecutor(…)…“

Anytime you have a method with And in its name, that's a cue to refactor that method into two more cohesive methods.

My advice is to spin off the two different aspects of buildAndCallExecutor(…) into two separate methods: (1) build() and (2) execute().

> „…There should be a way to declare the interface-typed variable…“

Here's a working demo of a more cohesive way to do that…

…
build( String name, U unambiguous, Type whichType ) {

    /* declare the interface-typed variable */
    Executioner< U > executioner;
    
    switch( whichType ) { 
        case FIRST: 
            /* assign the variable */
            executioner = new Executioner< >( new FirstExecutor< U >( ), new FirstExecutionContext< U >( name, unambiguous ) );
            break;
        case SECOND:
            executioner = new Executioner< >( new SecondExecutor< U >( ), new SecondExecutionContext< U >( name, unambiguous ) );
            break;
         …
    }
}
…

> „…call the method outside the if block…“

I demonstrate a simple, more cohesive implementation of that as…

public class ExecutorWorker {

    public < U > void execute( Set< Executioner< U > > executioners ) {
        
        executioners.stream( ).forEach( Executioner::execute );
    }
}

Then you build() and call() separately…

…
Builder builder = new Builder( );

ExecutorWorker worker = new ExecutorWorker( );
    
Set< Executioner< Integer > > work = builder.build( 666 );

worker.execute( work );
…

An experimental run of that prints out…

SecondExecutor< S > { } - executing SecondExecutionContext< D > { name: SECOND, description: 666 }
FirstExecutor< F > { } - executing FirstExecutionContext< U > { name: FIRST, id: 666 }

            EXPERIMENT SUCCESSFUL

> „…Okay, this is a complex problem…“

For fun, I did this additional experiment to test out the degree of complexity the above design can be extended to.

I demonstrate a working implementation of giving a complex ExecutionContext to a complex Executor that executes() other simpler Executors…

…    
Set< Executioner< String > > woyk = builder.build( "K.I.S.S." );
        
Executor< ExecutionContext< Set< Executioner< String > > >, Set< Executioner< String > > > executor = new ComplexWorker< > ( );
        
ExecutionContext< Set< Executioner< String > > > complexWoyk = new ComplexExecutionCtx< >("It's complicated", woyk );
        
executor.execute( complexWoyk );
…

That prints…

…
ComplexWorker< CW >{ } - executing ComplexExecutionCtx< E, CTX > { name: It's complicated, complex: [executable.Executioner@27f674d, executable.Executioner@1d251891] }
FirstExecutor< F >{ } - executing FirstExecutionCtx< U > { name: FIRST, id: K.I.S.S. }
SecondExecutor< S >{ } - executing SecondExecutionCtx< D > { name: SECOND, description: K.I.S.S. }
…

I would do it like this if it were me…

public class ExecutorWorker {
    
    public void buildAndCallExecutor( String name, int id, String description, String type ) {

        if ( type.equals( "FIRST" ) ) {
            Executor< FirstExecutionContext > executor = new FirstExecutor( );
            FirstExecutionContext firstExecutionContext = new FirstExecutionContext( );
            firstExecutionContext.setName( name );
            firstExecutionContext.setId( id );
            
            executor.execute( firstExecutionContext );
            
        } else if ( type.equals( "SECOND" ) ) {
            Executor< SecondExecutionContext > executor = new SecondExecutor( );
            SecondExecutionContext secondExecutionContext = new SecondExecutionContext( );
            secondExecutionContext.setName( name );
            secondExecutionContext.setDescription( description );

            executor.execute( secondExecutionContext );
        }
    }
}