O padrão de design Cadeia de Responsabilidade (CoR) é um padrão comportamental poderoso que pode melhorar significativamente o desenvolvimento de back-end. Esse padrão permite passar solicitações por meio de uma cadeia de manipuladores, onde cada manipulador pode processar a solicitação ou passá-la para o próximo manipulador. Neste blog, exploraremos o padrão CoR a partir de uma perspectiva de backend, focando particularmente em sua aplicação na validação e processamento de solicitações em um serviço web, usando Java para nossos exemplos.

Quando usar o padrão de cadeia de responsabilidade

O padrão Chain of Responsibility é particularmente útil em sistemas back-end onde as solicitações podem exigir várias etapas de validação e processamento antes de serem finalizadas. Por exemplo, em uma API RESTful, as solicitações recebidas podem precisar ser validadas para autenticação, autorização e integridade de dados antes de serem processadas pela lógica de negócios principal. Cada uma dessas preocupações pode ser tratada por diferentes manipuladores na cadeia, permitindo uma clara separação de responsabilidades e código modular. Esse padrão também é benéfico em arquiteturas de middleware, onde diferentes componentes de middleware podem lidar com solicitações, permitindo processamento flexível com base em critérios específicos.

Estrutura do Padrão de Cadeia de Responsabilidade

O padrão CoR consiste em três componentes principais: o manipulador, os manipuladores de concreto e o cliente. O Handler define a interface para lidar com solicitações e mantém uma referência para o próximo manipulador na cadeia. Cada Concrete Handler implementa a lógica para um tipo específico de processamento de solicitação, decidindo se deve tratar a solicitação ou repassá-la para o próximo manipulador. O Cliente envia solicitações para a cadeia de manipuladores, sem saber qual manipulador irá processar a solicitação. Essa dissociação promove capacidade de manutenção e flexibilidade no sistema backend.

Exemplo de implementação em Java

Etapa 1: definir a interface do manipulador

Primeiro, definiremos uma interface RequestHandler que inclui métodos para definir o próximo manipulador e processar solicitações:

abstract class RequestHandler {
    protected RequestHandler nextHandler;

    public void setNext(RequestHandler nextHandler) {
        this.nextHandler = nextHandler;
    }

    public void handleRequest(Request request) {
        if (nextHandler != null) {
            nextHandler.handleRequest(request);
        }
    }
}

Etapa 2: criar manipuladores de concreto

A seguir, criaremos classes manipuladoras concretas que estendem a classe RequestHandler, cada uma responsável por um aspecto específico do processamento de solicitações:

class AuthenticationHandler extends RequestHandler {
    @Override
    public void handleRequest(Request request) {
        if (request.isAuthenticated()) {
            System.out.println("Authentication successful.");
            super.handleRequest(request);
        } else {
            System.out.println("Authentication failed.");
            request.setValid(false);
        }
    }
}

class AuthorizationHandler extends RequestHandler {
    @Override
    public void handleRequest(Request request) {
        if (request.isAuthorized()) {
            System.out.println("Authorization successful.");
            super.handleRequest(request);
        } else {
            System.out.println("Authorization failed.");
            request.setValid(false);
        }
    }
}

class DataValidationHandler extends RequestHandler {
    @Override
    public void handleRequest(Request request) {
        if (request.isDataValid()) {
            System.out.println("Data validation successful.");
            super.handleRequest(request);
        } else {
            System.out.println("Data validation failed.");
            request.setValid(false);
        }
    }
}

class BusinessLogicHandler extends RequestHandler {
    @Override
    public void handleRequest(Request request) {
        if (request.isValid()) {
            System.out.println("Processing business logic...");
            // Perform the main business logic here
        } else {
            System.out.println("Request is invalid. Cannot process business logic.");
        }
    }
}

Etapa 3: Configurando a Cadeia

Agora, vamos configurar a cadeia de manipuladores com base em suas responsabilidades:

public class RequestProcessor {
    private RequestHandler chain;

    public RequestProcessor() {
        // Create handlers
        RequestHandler authHandler = new AuthenticationHandler();
        RequestHandler authzHandler = new AuthorizationHandler();
        RequestHandler validationHandler = new DataValidationHandler();
        RequestHandler logicHandler = new BusinessLogicHandler();

        // Set up the chain
        authHandler.setNext(authzHandler);
        authzHandler.setNext(validationHandler);
        validationHandler.setNext(logicHandler);

        this.chain = authHandler; // Start of the chain
    }

    public void processRequest(Request request) {
        chain.handleRequest(request);
    }
}

Etapa 4: Código do Cliente

Veja como o código do cliente interage com a cadeia de processamento de solicitações:

public class Main {
    public static void main(String[] args) {
        RequestProcessor processor = new RequestProcessor();

        // Simulating a valid request
        Request validRequest = new Request(true, true, true);
        processor.processRequest(validRequest);

        // Simulating an invalid request
        Request invalidRequest = new Request(true, false, true);
        processor.processRequest(invalidRequest);
    }
}

Aula de apoio

Aqui está uma classe Request simples que será usada para encapsular os dados da solicitação:

class Request {
    private boolean authenticated;
    private boolean authorized;
    private boolean dataValid;
    private boolean valid = true;

    public Request(boolean authenticated, boolean authorized, boolean dataValid) {
        this.authenticated = authenticated;
        this.authorized = authorized;
        this.dataValid = dataValid;
    }

    public boolean isAuthenticated() {
        return authenticated;
    }

    public boolean isAuthorized() {
        return authorized;
    }

    public boolean isDataValid() {
        return dataValid;
    }

    public boolean isValid() {
        return valid;
    }

    public void setValid(boolean valid) {
        this.valid = valid;
    }
}

Explicação de saída

Ao executar o código do cliente, você observará a seguinte saída:

Authentication successful.
Authorization successful.
Data validation successful.
Processing business logic...
Authentication successful.
Authorization failed.
Request is invalid. Cannot process business logic.

• A primeira solicitação é processada com sucesso por todos os manipuladores, demonstrando que toda a cadeia está funcionando conforme o esperado.
• A segunda solicitação falha durante a etapa de autorização, interrompendo o processamento adicional e evitando que solicitações inválidas cheguem à lógica de negócios.

Benefícios do Padrão de Cadeia de Responsabilidade

1. Separação de preocupações: Cada manipulador tem uma responsabilidade distinta, tornando o código mais fácil de entender e manter. Essa separação permite que as equipes se concentrem em aspectos específicos do processamento de solicitações sem se preocupar com todo o fluxo de trabalho.

2. Tratamento flexível de solicitações: Manipuladores podem ser adicionados ou removidos sem alterar a lógica existente, permitindo fácil adaptação a novos requisitos ou mudanças nas regras de negócios. Essa modularidade suporta práticas de desenvolvimento ágil.

3. Manutenibilidade aprimorada: A natureza dissociada dos manipuladores significa que as alterações em um manipulador (como a atualização da lógica de validação) não afetam outros, minimizando o risco de introdução de bugs no sistema.

4. Testes mais fáceis: manipuladores individuais podem ser testados isoladamente, simplificando o processo de teste. Isso permite testes de unidade direcionados e depuração mais direta de etapas específicas de processamento de solicitações.

Desvantagens

1. Sobrecarga de desempenho: uma longa cadeia de manipuladores pode introduzir latência, especialmente se muitas verificações precisarem ser realizadas sequencialmente. Em aplicações de desempenho crítico, isso pode se tornar uma preocupação.

2. Complexidade no controle de fluxo: embora o padrão simplifique as responsabilidades individuais do manipulador, ele pode complicar o fluxo geral de tratamento de solicitações. Compreender como as solicitações são processadas por meio de vários manipuladores pode exigir documentação e esforço adicionais para novos membros da equipe.

Conclusão

O padrão Chain of Responsibility é um padrão de design eficaz no desenvolvimento de back-end que aprimora o processamento de solicitações, promovendo a separação de preocupações, flexibilidade e capacidade de manutenção. Ao implementar esse padrão para validação e processamento de solicitações, os desenvolvedores podem criar sistemas robustos e escaláveis, capazes de lidar com vários requisitos com eficiência. Seja em uma API RESTful, no processamento de middleware ou em outros aplicativos de back-end, adotar o padrão CoR pode levar a um código mais limpo e a um design arquitetônico aprimorado, resultando em soluções de software mais confiáveis ​​e de fácil manutenção.