Questão de Engenharia de Software — Geral — FUNDATEC 2026

Padrão de Projeto Chain of Responsibility (Cadeia de Responsabilidade)

Gabarito: letra D. O atributo next na classe BancoChain referencia outro objeto da mesma classe, criando uma associação autorreferenciada que permite encadear instâncias — exatamente a estrutura do padrão de projeto Chain of Responsibility (Cadeia de Responsabilidade). As subclasses BancoA, BancoB, BancoC e BancoD herdam esse atributo e podem redefinir o método processRequest, especializando o comportamento ao longo da cadeia.

O padrão Chain of Responsibility é um padrão de projeto comportamental que desacopla o remetente de uma solicitação de seus receptores, dando a múltiplos objetos a oportunidade de tratar a solicitação. A ideia central é formar uma cadeia de objetos receptores, onde cada um decide se processa a requisição ou a repassa para o próximo elo da corrente. No diagrama apresentado, a classe BancoChain é a classe base (abstrata ou concreta) que define o método processRequest(bankName: String) e mantém o atributo next, que aponta para o próximo objeto da cadeia. As subclasses BancoA, BancoB, BancoC e BancoD herdam essa estrutura e podem sobrescrever (override) o método processRequest para implementar sua lógica específica de tratamento.

Na prática, o fluxo funciona assim: quando uma requisição chega ao primeiro elo da cadeia (por exemplo, BancoA), o método processRequest é chamado. Se BancoA consegue tratar a requisição (por exemplo, se o nome do banco corresponde ao seu), ele a processa e encerra. Caso contrário, ele repassa a requisição para o próximo elo (next), que pode ser BancoB, e assim sucessivamente até o fim da cadeia. Esse mecanismo permite que o sistema decida dinamicamente qual objeto tratará cada solicitação, sem acoplar o remetente a um receptor específico.

A distinção crucial que a banca explora aqui é entre Chain of Responsibility e Observer. No Observer, um sujeito (subject) mantém uma lista de observadores e notifica todos eles sobre mudanças de estado — é uma relação de um-para-muitos, onde todos os observadores são avisados simultaneamente. No Chain of Responsibility, a requisição percorre a cadeia sequencialmente, e apenas um elo (o primeiro que conseguir tratar) processa a solicitação — os demais não são notificados. Essa diferença é fundamental: no Observer, todos recebem a notificação; na Cadeia de Responsabilidade, apenas um trata.

Outro ponto que merece atenção é a herança e o polimorfismo. As subclasses BancoA, BancoB, BancoC e BancoD herdam de BancoChain e podem (e geralmente devem) redefinir o método processRequest para implementar comportamentos específicos. Isso é a essência do polimorfismo: o mesmo método pode ter implementações diferentes em cada subclasse. A alternativa que afirma que as subclasses "não podem redefinir" o método está errada, pois a herança justamente permite a sobrescrita de métodos.

A pegadinha da questão está em associar o diagrama ao padrão Observer (alternativa C). O candidato que conhece superficialmente os padrões pode confundir a estrutura de encadeamento com a de notificação. No entanto, o atributo next apontando para outro objeto da mesma classe é a assinatura clássica da Cadeia de Responsabilidade, não do Observer. Guarde essa distinção: cadeia = sequencial, um trata; observer = broadcast, todos recebem.

Alternativa A — ❌ Incorreta

Afirma que apenas uma instância de BancoChain pode existir no sistema. Isso caracterizaria o padrão Singleton, que restringe a criação de objetos a uma única instância. No diagrama, o atributo next referencia outro objeto da mesma classe, o que implica a existência de múltiplas instâncias encadeadas. Não há nenhuma indicação de restrição de instanciação — pelo contrário, a cadeia pressupõe vários objetos.

Alternativa B — ❌ Incorreta

Afirma que as subclasses BancoA, BancoB, BancoC e BancoD não podem redefinir o método processRequest. Isso contraria o princípio da herança e do polimorfismo em orientação a objetos. As subclasses herdam o método da superclasse e podem sobrescrevê-lo (override) para especializar o comportamento. O enunciado inclusive afirma que elas "podem especializar o comportamento desse método", o que confirma a possibilidade de redefinição.

Alternativa C — ❌ Incorreta

Afirma que o diagrama representa o padrão Observer, no qual múltiplos objetos recebem notificações de mudanças de estado. Essa é a pegadinha central da questão. No Observer, o sujeito mantém uma lista de observadores e notifica todos sobre mudanças — relação de um-para-muitos com broadcast. No diagrama, o atributo next cria uma cadeia sequencial onde a requisição passa de um elo para o próximo, e apenas um objeto trata a solicitação. A estrutura é de Chain of Responsibility, não de Observer.

Alternativa D — ✅ Correta ⟵ GABARITO

Afirma que o atributo next indica uma associação entre objetos da classe BancoChain, permitindo o encadeamento de instâncias. Isso está correto e descreve com precisão o mecanismo do padrão Chain of Responsibility. O atributo next é uma referência autorreferenciada (associação reflexiva) que liga um objeto da cadeia ao próximo, formando uma corrente de responsabilidade. Cada elo sabe quem é o próximo, permitindo que a requisição percorra a cadeia até encontrar um objeto capaz de tratá-la.

Alternativa E — ❌ Incorreta

Afirma que o método processRequest só pode ser executado pela classe BancoChain, não podendo ser utilizado pelas subclasses. Isso é falso: as subclasses herdam o método e podem sobrescrevê-lo para implementar comportamentos específicos. Na verdade, o padrão Chain of Responsibility depende da sobrescrita do método pelas subclasses para que cada elo da cadeia tenha sua lógica própria de tratamento. Sem a redefinição, todas as instâncias se comportariam de forma idêntica, o que tornaria a cadeia inútil.

Gabarito: letra D — o atributo next cria a associação autorreferenciada que permite o encadeamento de instâncias, caracterizando o padrão Chain of Responsibility.