Java – chain of responsibility: cycle or next step?

I am implementing a series of responsibility models

I have different policies that can be combined into a list, and I have a processor to process the policy list Each policy can process custominput and can choose whether other policies should be processed

interface Policy {    
  public boolean process(CustomInput input);    
}

interface Processor {    
  public void process(List<Policy> policies,CustomInput input)    
}

I'll implement a processor loop through the list of policies and check the Boolean results of each policy to see whether to continue with other policies

My colleagues suggest that they call (or not) the next policy (such as filterchain) through the next policy to each policy

My questions are as follows:

Without seeing any benefits in the second solution (from the next policy to the currently processed solution), loop through each policy and check its results?

Solution

It doesn't make sense for me to pass the idea of the next one So I want a chain:

A - B - C - D

How does C know D? If it is in C code, any change to the chain will be a huge trouble to implement

The chain needs to follow some other paths that already exist, such as what the responders do when they just ask for help from each parent (in the case of the gang of four), or you need to build the chain, which is why at the bottom of the go4 section, they mention that the compound pattern is a natural accomplice

Please note that one of the main reasons for the responsibility chain is that the types of operations on the project may be different This makes it perfect to implement it with an interface in Java

Answer your main question: in this case, the benefits of using the responsibility chain are two aspects: 1 You don't make a god object, know everything that can happen to achieve your goal (successfully establish a policy), and 2 You don't have to put a lot of ugly check code to see when you arrive at the terminal because who handles it will prompt the return of the completed project by not calling its successor