Não entendi a necessidade desse padrão de projeto para o problema apresentado

Olá, Lucas.

O Decorator e o Chain of Responsibility são meio primos, né?

O Decorator é estrutural e trata de compor objetos. O Chain é "comportamental" e trata evitar que a classe que chama dependa de um monte de outras classes. Pelo GoF, os objetos da cadeia iam repassando até algum conseguir dar uma resposta (meio parecido com tratamento de exceptions)

Acho que no caso do filtro, a ideia é compor. Não faria sentido parar de filtrar, né?

Peguei aqui minha cópia do Design Patterns do GoF pra referência:

Decorator

Object Structural Intent

Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

Chain of Responsibility

Object Behavioral

Intent

Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.

Entendi, não tinha pego esse detalhe de comportamental e composição, agora ficou mais claro. Obrigado

Oi Lucas a ideia é poder ter filtros que podem ser decorados de outros filtros para filtrar contas.No caso do chain seria interessante se quiséssemos montar uma cadeia onde cada filtro teria um próximo e não nos preocuparíamos com qual deles atendêssemos a solicitação do cliente. É comum para dada um problema de projeto vários padrões candidatos mas nesse caso em especifico como devemos montar estruturalmente objetos filtro que são decorados por outros filtros o padrão candidato é o Decorator mesmo.

Espero ter ajudado e bons estudos.