SOLID — Princípio Aberto Fechado
Nesse artigo vamos abordar o segundo princípio do SOLID, o Princípio Aberto Fechado (Open Closed Principle).
O OCP diz que:
Software entities should be open for extension, but closed for modification.
Essencialmente quer dizer que entidades de software (classes, módulos, funções, etc) devem permitir que suas funcionalidades sejam estendidas, mas não permitir modificações no seu próprio código-fonte.
Benefícios:
Esse princípio visa reduzir a introdução de bugs e outros erros em seu código, exigindo que as classes não alterem sua própria implementação, a menos que seja absolutamente necessário, já que outras classes derivadas ou implementadas podem depender dessa implementação para funcionar adequadamente.
Esse princípio também sugere que se implementem classes que possam facilmente ter sua funcionalidade estendida e, ao permitir que a classe seja aberta para extensão, permitimos que muitas mudanças reais possam ocorrer sem impacto em outras partes do projeto.
Vamos ver um exemplo que viola esse princípio, simulando uma classe que calcula salários de desenvolvedores. Os exemplos aqui estão escritos em C#, mas podem ser reproduzidos em qualquer linguagem orientada a objetos.
Ao fazer isso, violamos o Princípio Aberto Fechado. Para estender a funcionalidade da classe CalculateSalary.cs, teremos que modificar seu código-fonte. Já se quisermos incluir um novo nível de desenvolvedor sênior, teremos que adicionar uma nova cláusula ao switch/case do método Calculate.
Essencialmente, a classe CalculateSalary.cs não está fechada para modificação e não está realmente aberta para extensão, por isso, precisaremos refatorar, criando uma classe abstrata que vai expor um método também abstrato:
Iniciaremos adicionando um novo nível de desenvolvedor para estender nosso código corretamente:
Agora criaremos mais três classes herdadas da CalculateSalary.cs, uma para cada tipo de cálculo de salário.
Assim, nossas classes estão fechadas para modificação e abertas para extensão, com a implementação de cada cálculo em classes separadas que não precisam mais serem alteradas. Caso seja necessário adicionar mais um nível de desenvolvedor, podemos estender novamente.
Para testar na nossa classe Program.cs, criamos uma lista de CalculateSalary com cada um dos subtipos, e rodamos o método Calculate dentro de um foreach, como mostra o trecho de código a seguir:
Outra alternativa para esse problema seria criar uma Factory, que ficará responsável pela criação desses objetos baseados no Level passado via parâmetro:
Diferente do exemplo onde mostramos a violação do OCP, essa classe também possui o mesmo switch/case, mas com a única responsabilidade de orquestrar a criação de objetos do tipo CalculateSalary. Isto faz com que a mesma só sofra alterações caso surja um novo nível de desenvolvedor no negócio, o que não impactará na implementação dos outros cálculos.
Na classe Program.cs, usamos a CalculateSalaryFactory da seguinte forma:
Devemos ter em mente que a expressão “fechada para modificação” não significa que a classe nunca mais possa ser alterada. Requisitos de software mudam, e, em um dado momento, poderá ser necessária a alteração da lógica de cálculo do salário, neste caso, devemos alterar as classes sem medo.
Assim, finalizamos o segundo princípio. Na semana que vem, publicaremos o terceiro artigo que será sobre o Princípio de Substituição de Liskov. Até a próxima.
Link dos exemplos no GitHub.
Links para todos os artigos sobre SOLID:
Princípio da Responsabilidade Única (SRP)
Princípio de Substituição de Liskov (LSP)
