Uma equipe de desenvolvimento da SEFAZ-Nacional está implementando um módulo de cálculo de tributos que precisa suportar diferentes regimes de tributação (Simples Nacional, Lucro Presumido e Lucro Real). O arquiteto propôs o seguinte desenho:

• Uma interface RegimeTributario com o método calcularImposto(NotaFiscal nf).
• Classes concretas SimplesNacional, LucroPresumido e LucroReal que implementam a interface.
• Uma classe CalculadoraTributos que recebe, via injeção de dependência, um objeto RegimeTributario e delega o cálculo.
• Um TributoFactory que, a partir de uma configuração externa (arquivo properties), instancia o regime adequado em tempo de execução.

Durante a revisão de código, foram levantadas as seguintes observações:

I. O desenho aplica o princípio aberto/fechado (OCP), pois novos regimes podem ser adicionados sem alterar CalculadoraTributos, mas a TributoFactory precisará ser modificada para reconhecer o novo regime, o que caracteriza uma violação parcial do OCP nesse ponto específico.

II. A injeção de dependência em CalculadoraTributos promove inversão de controle e reduz o acoplamento, permitindo substituir o regime tributário em testes unitários sem alterar a classe.

III. O uso de uma interface RegimeTributario com múltiplas implementações caracteriza polimorfismo de inclusão, em que a chamada a calcularImposto é resolvida em tempo de execução conforme o tipo concreto do objeto.

IV. A TributoFactory, ao instanciar diretamente as classes concretas, viola o princípio da inversão de dependência (DIP), pois módulos de alto nível (CalculadoraTributos) não deveriam depender de módulos de baixo nível, mas ambos deveriam depender de abstrações; contudo, como a fábrica é um módulo de composição, essa dependência é considerada aceitável em arquiteturas limpas.

Está correto o que se afirma em: