Ao construir uma aplicação bancária, um projetista de software modelou a classe Conta. Posteriormente, percebeu que cada instância da classe Conta poderia ter um conjunto de responsabilidades variadas e independentes, sendo que uma requisição poderia ter que ser atendida por uma ou várias dessas responsabilidades. Isso não permitiria usar de forma eficiente o mecanismo de subclasses para representar essas responsabilidades. Buscando uma solução adequada para essa limitação, o projetista encontrou um padrão de projeto que permite adicionar e retirar dinamicamente responsabilidades apenas aos objetos individuais, e não à classe inteira, estendendo a funcionalidade do objeto, o que seria a solução ideal para o seu caso.
Esse padrão de projeto específico tem uma estrutura comum, em que existe uma
A) superclasse abstrata, por exemplo ComponenteConta, que também é superclasse de uma segunda classe, e essa segunda classe, também abstrata, será superclasse das várias classes concretas que representam as responsabilidades adicionais.
B) classe, por exemplo InterfaceConta, que converte a interface de uma classe em outra interface que o cliente espera, evitando incompatibilidades causadas por interfaces diferentes.
C) classe, por exemplo FabricaContas, que separa a construção de um objeto complexo da sua representação, de forma que o mesmo processo de construção possa criar diferentes representações.
D) classe que define uma dependência um-para-muitos entre objetos, de forma que, quando o estado de um objeto da classe Conta é alterado, todos os outros objetos dependentes são notificados e podem implementar atualização automática de suas propriedades, em uma relação publicar-subscrever.
E) classe abstrata, por exemplo InterfaceConta, cuja finalidade é definir a interface que permite que suas subclasses tratem uma requisição, sendo que as subclasses concretas são estruturadas em uma cadeia onde cada classe trata a requisição ou a envia para a classe sucessora, até que uma delas atenda a requisição.