Stack Exchange
spring too many constructors argument using the same interface with qualifiers
This is more like a "good practice" question.
let's say i have an interface "MyInterface" and about 15 implementations of it. 
I have an Object called "MyProcess" and the code looks like 
private final List<MyInterface> myInterfaces;

public MyProcess(@Qualifier("impl1") MyInterface impl1,
                 @Qualifier("impl2") MyInterface impl2,
                 @Qualifier("impl3") MyInterface impl3,
                 @Qualifier("impl4") MyInterface impl4,
                 @Qualifier("impl5") MyInterface impl5,
                 @Qualifier("impl6") MyInterface impl6,
                 @Qualifier("impl7") MyInterface impl7,
                 @Qualifier("impl8") MyInterface impl8) {

this.myInterfaces = Stream
            .of(impl1,
                impl2,
                impl3,
                impl4,
                impl5,
                impl6,
                impl7,
                impl8)
            .collect(toList());
    }

The goal is to define different processes using some of the implementations of MyInterface in a specific order. The issue is that sonar rule S107 (constructor has 8 parameters which is greater than 7 authorized) is showing. I was wondering if this was a code structure issue or if i just had to ignore sonar on this. I dont feel like breaking SRP since the only goal of MyProcess is to define the list of MyInterface it needs. 
Does anyone have a clue on how i could improve this code ? Maybe an other pattern to use ? 
Thank you in advance for your time

Is there a specific reason you aren't just using List<MyInterface> impls?

Create qualifiers to identify which proces it needs to attach to. Then autowire the list directly with the qualifiers (or filter in the constructor).

I can't just autowire the full list as there are several processes not using the same "chain" of MyInterface.
Processes are like recipes using different ingredients, but not necessarily in the same order nor exactly the same list of ingredient (i don't know if i'm clearer with such an exemple)

One alternative is to add a method name() to MyInterface, which is implemented in each subclass as returning a constant String.
public MyProcess(List<MyInterface> impls) {

  this.myInterfaces = new ArrayList<MyInterface>();
  for(String name: Arrays.asList("impl1", "impl2"...) {
     for(MyInterface impl: impls) {
       if(name.equals(impl.name())) {
         myInterfaces.add(impl); 
       }
     }
  }
}

I feel that hard-coding the names of the implementation in the process might not be ideal. If you already have 15 implementations, the odds are that you might in the future have to add one. And then you would need to update the Process as well.
You let the MyInterface return something else than a name, e.g. a 'purpose' and a 'priority', so the process could wire new implementations automatically in the correct place, but that depends on your usecase.

Thank's for the answer!
You are right on the fact that i might need to add one impl in the future. One issue is that the order is important. So if i need to add a new impl of MyInterface, let's say in 3rd position, i don't know how i can do that without editing the process. And having something returning a 'priority' in MyInterface seems hard since the priority may depends on the process. cf. my comment above with the example of recipes and ingredients. Maybe one recipe needs tomatoes first but the other one needs it only at the end. Let me know if its unclear

OK, then keeping the names of the steps in the process seems reasonable enough. Maybe just keep the Arrays.asList("impl1", "impl2"...) as a private static final field then with a nice name so you remember what it's for :-)

It is indeed a solution that reduces the constructor to one parameter only. But it doesn't feel like a improvement of the code quality, since it needs to define the name() method + it complexifies the construction of the implementations list. Between both what do you think is better in term of cleaner code ?

The name method replaces the @Qualifier annotation, so that doesn't change the complexity IMHO. And selecting the steps in the process seems to be an integral part of your domain logic, so I would prefer to see it in actual code rather than framework quirks.
It's also better testable, I think, if it's in plain Java code rather than via framework-dependent annotations.
