Como implementar regras de negócio que podem mudar com o passar do tempo sem violar o “Open/Closed Principle” do SOLID? Afinal, a violação desse princípio deixaria os códigos difíceis de manter além de implicar na escritas de testes que “quebrariam” pelos motivos errados.

Há anos, temos visto sempre os mesmos exemplos, triviais, porém distantes do “mundo real”, onde a solução para o desafio imposto pelo princípio implica em suportar alguma variação de polimorfismo.

public abstract class Employee
{
  // ...
  public abstract bool IsElegibleForRetirement();
  // ..
}

O problema destas abordagens é que elas ignoram cenários onde comportamentos expressos por mais de um elemento do contrato (mais de um método) variam independentemente. Além disso, soluções baseadas em herança geram evidente custo de acoplamento.

Uma solução, mais elegante em nossa opinião, possível em diversos cenários, é recorrer a adoção do Specification pattern.

Specification Pattern é um padrão de design de software, onde regras de negócio podem ser recombinadas através de lógica booleana. (Wikipedia em tradução livre)

public class RetirementLaw_287_2016 : IRetirementSpecification
{
  public bool IsSatisfiedBy(Employee e) { /* .. */ }
} 

A “beleza” dessa abordagem é que ela se encaixa perfeitamente para, por exemplo, implementar suporte a leis e regulações (como no caso da lei de aposentadoria, indicado no exemplo). Assim, sempre que uma nova regulação entra em vigor, podemos criar uma nova versão da especificação. Outro ponto forte dessa ideia é a facilidade de tornar o código compreensível pelo especialista do domínio.

O que acha?