Questão nº 51
Questão de Tecnologia da Informação · FGV DATAPREV 2024 (nº 51)
Uma aplicação de e-commerce possui a seguinte classe Pedido, que cria diretamente uma instância de ServicoDePagamento e ServicoDeNotificacao para processar pagamentos e enviar notificações ao cliente:
```
public class Pedido {
private ServicoDePagamento servicoPagamento = new ServicoDePagamento();
private ServicoDeNotificacao servicoNotificacao = new ServicoDeNotificacao();
public void processarPedido() {
servicoPagamento.processarPagamento();
servicoNotificacao.enviarConfirmacao();
}
}
```
Este código viola o Princípio da Inversão de Dependência (DIP). Para seguir corretamente o DIP, deve-se refatorar o código
- Aremovendo a dependência de ServicoDePagamento e movendo a lógica de pagamento diretamente para a classe Pedido.
- Busando um padrão Singleton para ServicoDePagamento e ServicoDeNotificacao, garantindo que as instâncias sejam compartilhadas entre diferentes classes.
- Cintroduzindo interfaces IPagamento e INotificacao, e injetando-as via construtor na classe Pedido, permitindo a inversão de dependências para abstrações em vez de implementações concretas. (alternativa correta)
- Dalterando o código para usar herança, fazendo com que Pedido herde de uma classe abstrata que define os métodos de pagamento e notificação.
- Ecriando uma fábrica (Factory) que cria instâncias de ServicoDePagamento e ServicoDeNotificacao e as injeta na classe Pedido.
Resposta comentada
Gabarito Alternativa C
O Princípio da Inversão de Dependência (DIP) afirma que módulos de alto nível (que contêm a lógica de negócio principal) não devem depender de módulos de baixo nível (que contêm detalhes de implementação); ambos devem depender de abstrações (como interfaces). Em outras palavras, em vez de uma classe depender de uma implementação específica, ela deve depender de uma "ideia" ou "contrato" do que essa implementação faz.
(A) Incorreta: Remover a dependência e mover a lógica para `Pedido` aumentaria a responsabilidade da classe `Pedido` (violando o Princípio da Responsabilidade Única) e não resolveria a dependência em si, apenas a internalizaria.
(B) Incorreta: O padrão Singleton garante que haja apenas uma instância de uma classe, mas ainda envolve uma dependência direta de uma implementação concreta, não de uma abstração.
(C) Correta: Introduzir interfaces (`IPagamento`, `INotificacao`) e injetá-las via construtor faz com que a classe `Pedido` dependa de abstrações (as interfaces) em vez de implementações concretas (`ServicoDePagamento`, `ServicoDeNotificacao`). Isso inverte a dependência: agora, tanto a classe `Pedido` (módulo de alto nível) quanto os serviços (módulos de baixo nível) dependem das interfaces (abstrações).
(D) Incorreta: Usar herança cria um acoplamento forte entre a classe `Pedido` e a classe abstrata, não promovendo a flexibilidade e a inversão de dependência que o DIP busca através de interfaces e injeção.
(E) Incorreta: Uma fábrica (Factory) ajuda a gerenciar a criação de instâncias, mas a classe `Pedido` ainda dependeria de uma implementação concreta da fábrica para obter seus serviços, não de uma abstração diretamente. A armadilha aqui é que a fábrica parece desacoplar, mas o `Pedido` ainda estaria acoplado à fábrica em si, que por sua vez estaria acoplada aos serviços concretos. A injeção de interfaces é mais direta para o DIP.
Fonte: FGV DATAPREV 2024 Analista de Tecnologia da Informação - Arquitetura, Engenharia e Sustentação Tecnológica (Caderno Tipo 1). Reproduzida para fins de estudo.