Analista Judiciário - Área Apoio Especializado - Especialidade: Análise de Sistemas de Informação
O analista Joaquim implementou o código do sistema TRF1Web seguindo os princípios SOLID. O TRF1Web já se encontra em produção. A documentação do TRF1Web, escrita por Joaquim, estabelece que novas funcionalidades devem ser introduzidas no sistema por meio de plugins, sem modificar o código atual do sistema.Essa maneira de introduzir novas funcionalidades no TRF1Web é resultado direto da aplicação do seguinte princípio SOLID:
Aaberto/fechado;
Bsubstituição de Liskov;
Cresponsabilidade única;
Dsegregação de interfaces;
Einversão de dependência.
Revelar gabarito e comentário▾
GabaritoA — aberto/fechado;
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Princípio Aberto/Fechado (Open/Closed Principle)
Gabarito: letra A. A possibilidade de introduzir novas funcionalidades por meio de plugins, sem modificar o código existente, é a aplicação direta do princípio aberto/fechado (Open/Closed Principle — OCP), um dos cinco princípios SOLID. Esse princípio estabelece que as entidades de software devem estar abertas para extensão, mas fechadas para modificação — exatamente o que a documentação do TRF1Web descreve.
O princípio aberto/fechado foi formulado por Bertrand Meyer e é um dos pilares do design orientado a objetos. A ideia central é que, ao adicionar uma nova funcionalidade, você não deve alterar o código já testado e em produção — isso reduz o risco de introduzir bugs em funcionalidades existentes. Em vez disso, você estende o comportamento do sistema por meio de novos módulos (plugins, subclasses, composição), que se encaixam em pontos de extensão previamente definidos.
No caso do TRF1Web, a documentação estabelece que novas funcionalidades devem ser introduzidas por plugins, sem modificar o código atual. Isso é a materialização do OCP: o sistema está "aberto" para receber novos plugins (extensão) e "fechado" para alterações no código existente (modificação).
Os cinco princípios SOLID são:
S — Single Responsibility Principle (Responsabilidade Única): uma classe deve ter um, e somente um, motivo para mudar.
O — Open/Closed Principle (Aberto/Fechado): entidades devem ser abertas para extensão, mas fechadas para modificação.
L — Liskov Substitution Principle (Substituição de Liskov): subtipos devem ser substituíveis por seus tipos base sem alterar a corretude do programa.
I — Interface Segregation Principle (Segregação de Interfaces): clientes não devem ser forçados a depender de interfaces que não utilizam.
D — Dependency Inversion Principle (Inversão de Dependência): módulos de alto nível não devem depender de módulos de baixo nível; ambos devem depender de abstrações.
A pegadinha da banca está em confundir o OCP com o princípio da inversão de dependência (DIP). Embora ambos estejam relacionados à extensibilidade, o DIP trata da direção das dependências (depender de abstrações, não de implementações), enquanto o OCP trata da capacidade de estender sem modificar. A introdução de plugins é um exemplo clássico de OCP, pois os plugins são pontos de extensão que não exigem alteração no núcleo do sistema.
Princípios SOLID: S — Responsabilidade Única (Um único motivo para mudar); O — Aberto/Fechado (OCP) (Aberto para extensão, Fechado para modificação, Ex.: plugins sem alterar código); L — Substituição de Liskov (Subtipo substituível pelo tipo base); I — Segregação de Interfaces (Cliente não depende do que não usa); D — Inversão de Dependência (Depender de abstrações)
Alternativa A — ✅ Correta ⟵ GABARITO
O princípio aberto/fechado (OCP) determina que o software deve ser aberto para extensão (permitir adicionar novas funcionalidades) e fechado para modificação (não alterar o código existente). A introdução de novas funcionalidades por meio de plugins, sem modificar o código atual, é a aplicação direta desse princípio. O sistema TRF1Web está aberto para receber novos plugins (extensão) e fechado para alterações no código já em produção (modificação).
Alternativa B — ❌ Incorreta
O princípio da substituição de Liskov (LSP) trata da relação entre tipos base e subtipos: se S é um subtipo de T, então objetos do tipo T podem ser substituídos por objetos do tipo S sem alterar a corretude do programa. Não tem relação com a introdução de novas funcionalidades por plugins. A banca tenta confundir o candidato que lembra apenas os nomes dos princípios, sem dominar o conteúdo de cada um.
Alternativa C — ❌ Incorreta
O princípio da responsabilidade única (SRP) afirma que uma classe deve ter um único motivo para mudar, ou seja, deve ter uma única responsabilidade. Não está relacionado à extensão do sistema por plugins. A confusão aqui é achar que "responsabilidade única" se refere à separação de funcionalidades em módulos, mas o SRP é sobre coesão interna de uma classe, não sobre extensibilidade.
Alternativa D — ❌ Incorreta
O princípio da segregação de interfaces (ISP) preconiza que clientes não devem ser forçados a depender de interfaces que não utilizam. Isso significa criar interfaces específicas em vez de uma interface genérica. Não tem relação com a introdução de plugins. A banca pode tentar confundir com a ideia de "interfaces" como pontos de extensão, mas o ISP trata da granularidade das interfaces, não da extensão do sistema.
Alternativa E — ❌ Incorreta
O princípio da inversão de dependência (DIP) estabelece que módulos de alto nível não devem depender de módulos de baixo nível, mas ambos devem depender de abstrações. Embora o DIP seja frequentemente usado para implementar o OCP (por exemplo, usando interfaces para permitir extensão), a introdução de plugins por si só é uma manifestação do OCP, não do DIP. O DIP é uma técnica que ajuda a alcançar o OCP, mas o enunciado descreve diretamente o OCP.
NÃO CAIA NESSA!
A banca explora a confusão entre o princípio aberto/fechado (OCP) e o princípio da inversão de dependência (DIP). Ambos estão ligados à extensibilidade, mas o OCP é o que diz "aberto para extensão, fechado para modificação" — exatamente o que o enunciado descreve. O DIP é uma forma de implementar o OCP, mas não é o princípio que o enunciado nomeia. Fique atento: quando a questão falar em "plugins", "extensões", "sem modificar o código existente", a resposta quase sempre é o OCP.