Instance created by new depend on @Service member operation

Question

First, please let me introduce a minimal scene demo to explain the problem.

Let's say i have a strategy pattern interface.

public interface CollectAlgorithm<T> {
    public List<T> collect();
}

And a implementation of this strategy, the ConcreteAlgorithm.

public class ConcreteAlgorithm implements CollectAlgorithm<Integer> {

    @Resource
    QueryService queryService;

    @Override
    public List<Integer> collect() {
        // dummy ...
        return Lists.newArrayList();
    }
}

As you can see, the implementation depend on some query operation provided by a @Service component.

The ConcreteAlgorithm class will be created by new in some places, then the collect method will be called.

I've read some related link like Spring @Autowired on a class new instance, and know that the above code cannot work, since the instance created by new has a @Resource annotated member.

I'm new to Spring/Java, and i wonder if there are some ways, or different design, to make scene like above work.

I've thought about use factory method, but it seems that it will involve many unchecked type assignment since i provided a generic interface.

---

UPDATE

To make it more clear, i add some detail about the problem.

I provide a RPC service for some consumers, with an interface like:

public interface TemplateRecommendService {
    List<Long> recommendTemplate(TemplateRecommendDTO recommendDTO);
}

@Service
public class TemplateRecommandServiceImpl implements TemplateRecommendService {

    @Override
    public List<Long> recommendTemplate(TemplateRecommendDTO recommendDTO) {
        TemplateRecommendContext context = TemplateRecommendContextFactory.getContext(recommendDTO.getBizType());
        return context.process(recommendDTO);
    }
}

As you can see, i will create different context by a user pass field, which represent different recommendation strategy. All the context should return List<Long>, but the pipeline inside context is totally different with each other.

Generally there are three main stage of the context process pipeline. Each stage's logic might be complicated and varied. So there exists another layer of strategy pattern.

public abstract class TemplateRecommendContextImpl<CollectOut, PredictOut> implements TemplateRecommendContext {
    private CollectAlgorithm<CollectOut> collectAlgorithm;

    private PredictAlgorithm<CollectOut, PredictOut> predictAlgorithm;

    private PostProcessRule<PredictOut> postProcessRule;

    protected List<CollectOut> collect(TemplateRecommendDTO recommendDTO){
        return collectAlgorithm.collect(recommendDTO);
    }

    protected List<PredictOut> predict(TemplateRecommendDTO recommendDTO, List<CollectOut> predictIn){
        return predictAlgorithm.predict(recommendDTO, predictIn);
    }

    protected List<Long> postProcess(TemplateRecommendDTO recommendDTO, List<PredictOut> postProcessIn){
        return postProcessRule.postProcess(recommendDTO, postProcessIn);
    }

    public /*final*/ List<Long> process(TemplateRecommendDTO recommendDTO){
        // pipeline:
        // dataCollect -> CollectOut -> predict -> Precision -> postProcess -> Final
        List<CollectOut> collectOuts = collect(recommendDTO);
        List<PredictOut> predictOuts = predict(recommendDTO, collectOuts);
        return postProcess(recommendDTO, predictOuts);
    }
}

As for one specific RecommendContext, its creation likes below:

public class ConcreteContextImpl extends TemplateRecommendContextImpl<GenericTempDO, Long> {
    // collectOut, predictOut
    ConcreteContextImpl(){
        super();
        setCollectAlgorithm(new ShopDecorateCrowdCollect());
        setPredictAlgorithm(new ShopDecorateCrowdPredict());
        setPostProcessRule(new ShopDecorateCrowdPostProcess());
    }
}

Answer 1

Instead od using field oriented autowiring use constructor oriented one - that will force the user, creating the implementation instance, to provide proper dependency during creation with new

@Service
public class ConcreteAlgorithm implements CollectAlgorithm<Integer> {
    private QueryService queryService;

    @Autowired // or @Inject, you cannot use @Resource on constructor
    public ConcreteAlgorithm(QueryService queryService) {
        this.queryService = queryService;
    }

    @Override
    public List<Integer> collect() {
        // dummy ...
        return Lists.newArrayList();
    }
}

Answer 2

There are 4 (+1 Bonus) possible approaches I can think of, depending on your "taste" and on your requirements.

---

1. Pass the service in the constructor.

When you create instances of your ConcreteAlgorithm class you provide the instance of the QueryService. Your ConcreteAlgorithm may need to extend a base class.

    CollectAlgorithm<Integer> myalg = new ConcreteAlgorithm(queryService);
    ...

This works when the algorithm is a stateful object that needs to be created every time or, with some variations, when you actually don't know the algorithm at all as it comes from another library (in which case you might have a factory or, in rare cases which most likely don't fit your scenario, create the object through reflection).

2. Turn your algorithm into a @Component

Annotate your ConcreteAlgorithm with the @Component annotation and then reference it wherever you want. Spring will take care of injecting the service dependency when the bean is created.

    @Component
    public class ConcreteAlgorithm implements CollectAlgorithm<Integer> {

        @Resource
        QueryService queryService;

        ....

    }

This is the standard and usually preferred way in Spring. It works when you know ahead of time what all the possible algorithms are and such algorithms are stateless. This is the typical scenario. I don't know if it fits your needs but I would expect most people to be looking for this particular option.

Note that in the above scenario the recommendation is to use constructor-based injection. In other words, I would modify your implementation as follows:

    @Component
    public class ConcreteAlgorithm implements CollectAlgorithm<Integer> {

        final QueryService queryService;

        @Autowired
        public ConcreteAlgorithm(QueryService queryService) {
            this.queryService = queryService;
        }

        @Override
        public List<Integer> collect() {
            // dummy ...
            return Lists.newArrayList();
        }
    }

On the most recent versions of Spring you can even omit the @Autowired annotation.

3. Implement and call a setter

Add a setter for the QueryService and call it as needed.

    CollectAlgorithm<Integer> myalg = new ConcreteAlgorithm();
    myalg.setQueryService(queryService);
    ...

This works in scenarios like those of (1), but lifts you from the need of passing parameters to the constructor, which "may" help getting rid of reflection in some cases. I don't endorse this particular solution however as it forces to know that you have to call the setQueryService method prior to invoking other methods. Quite error-prone.

4. Pass the QueryService directly to your collect method.

Possibly the easiest solution.

    public interface CollectAlgorithm<T> {
        public List<T> collect(QueryService queryService);
    }

    public class ConcreteAlgorithm implements CollectAlgorithm<Integer> {

        @Override
        public List<Integer> collect(QueryService queryService) {
            // dummy ...
            return Lists.newArrayList();
        }
    }

This works well if you want your interface to be a functional one, to be used in collections.

Bonus: Spring's SCOPE_PROTOTYPE

Spring doesn't only allow to instantiate singleton beans but also prototype beans. This effectively means it will act as a factory for you.

I will leave this to an external example, at the following URL:

https://www.boraji.com/spring-prototype-scope-example-using-scope-annotation

This "can" be useful in specific scenarios but I don't feel comfortable recommending it straight away as it's significantly more cumbersome.