Veja o índice completo do tópico “S.O.L.I.D”

Olá pessoas …

Até que enfim, chegamos ao final da série “S.O.L.I.D“, vamos agora ver a letra D do acróstico que define a sigla DIP Dependency Inversion Principle (Princípio da inversão de dependência).

Definição

Classes de alto nível não devem depender de classes de baixo nível. Ambas devem depender de abstrações; Isso quer dizer que na minha hierarquia de classes, as classes mais genéricas, não devem depender de classes  mais especializadas. (Veja: Generalização e Especialização). Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações. Com esta definição, eu quero dizer que as minhas classes abstratas devem ser sempre classes estáveis e os detalhes da implementação devem ficar nas classes mais instáveis.

O que NÃO vamos falar aqui

Neste artigo não iremos falar detalhadamente de:

• Classes estáveis x Classes instáveis;
• IoC (Inversion of Control);
• DI (Dependency Injection);
• Contêiner (Autofac, Ninject, Spring);

Mas prometo voltar aqui no futuro e corrigir os links para artigos sobre cada assunto que irei escrever.

Não confundir este princípio com Injeção de Dependência, injeção de Dependência é a ideia de injetar código através de algum contêiner ou framework que vai fazer isso para você.

Aqui, você vai inverter, não injetar, a maneira como você depende das coisas.

Problemas ao ferir o princípio

Quando ferimos o princípio da inversão de dependência, temos um código com baixa coesão e alto acoplamento. Dar manutenção em um código escrito desta maneira se torna complexo, uma vez que muitas classes dependem de outras classes concretas e as classes concretas não são estáveis.
Ferimos o princípio da responsabilidade única, uma vez que uma classe pode fazer coisas que não diz respeito à ela.
Em sistemas grandes, onde a customização em clientes se faz necessária, é praticamente impossível de conseguir uma boa customização.
Fica mais difícil escrever testes de unidade, pois não temos como garantir que todas as funcionalidades, ou parte sejam testadas.

Certo ou errado? Abaixo, iremos ver dois exemplos, começaremos pelo errado e onde erramos e em seguida o correto e o que corrigimos.

Ferindo o princípio

Isto está errado. Lembra do primeiro princípio? (Veja: Princípio da Responsabilidade Única). O código “errado” é reproduzido abaixo. [csharp]/* * Classe apenas para fins de exemplo e aprendizado. * Não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ using System; using System.Collections.Generic; namespace Solid.Errado { public class Cliente { #region Private Methods private void Adicionar() { Validar(); Console.WriteLine($"O cliente {Nome} foi inserido."); } private void Atualizar() { Validar(); Console.WriteLine($"O cliente {Nome} foi atualizado."); } #endregion Private Methods #region Public Properties public string CNPJ { get; set; } public int Codigo { get; set; } public DateTime DataCadastro { get; set; } public string Email { get; set; } public string Endereco { get; set; } public string Nome { get; set; } #endregion Public Properties #region Public Methods public void EnviarEmail() { Console.WriteLine($"O e-mail foi enviado para o endereço {Email}"); } public void Excluir(long id) { Console.WriteLine($"O cliente {Nome} foi excluído."); } public void Salvar() { if(Codigo != 0) Atualizar(); else Adicionar(); EnviarEmail(); } public IList<Cliente> Selecionar(long? id = null) { List<Cliente> result = new List<Cliente>(); return result; } public bool Validar() { if(String.IsNullOrWhiteSpace(Nome)) throw new Exception("O nome é obrigatório"); if(!Email.Contains("@")) throw new Exception("O e-mail não é válido"); if(CNPJ.Length != 14) throw new Exception("O CNPJ não é válido"); return true; } #endregion Public Methods } }[/csharp]

No código acima a classe de cliente é responsável por enviar e-mail, se validar, realizar CRUD,  tem acesso ao banco de dados, conhece a implementação do envio de e-mail, enfim. Faz tudo que não se pode fazer.

Realizar a manutenção neste código seria trabalhoso, demorado e totalmente passível de erros.
É demasiado complicado realizar um teste de unidade.

Corrigindo o princípio

Isto está correto.

Aqui, iremos mostrar os fontes e detalhar as classes que foram comentadas no primeiro princípio. (Veja: Princípio da Responsabilidade Única).
Vamos definir aqui a classe de clientes com algumas alterações, para remover a depêndencia com validações, envios de e-mail e estratégias.

Podemos perceber que na classe de clientes, eu não tenho nenhuma chamada para validação e envio de e-mails, mas isto irá acontecer em nossa estratégia.

Devido ao fato de sempre trabalhar com sistemas ERP, onde se exige muitas customizações e mudanças de regras de negócio, é por isso que eu utilizo o Strategy Pattern.

[csharp]/*
* Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework.
*/

using Solid.Certo.Persistence.Abstract;
using Solid.Certo.Repository;
using System;

namespace Solid.Certo.Persistence
{
public class Cliente: EntityBase
{
#region Public Properties

public string CNPJ { get; set; }
public DateTime DataCadastro { get; set; }
public string Email { get; set; }
public string Endereco { get; set; }
public string Nome { get; set; }

#endregion Public Properties

#region Public Methods

public override void Salvar()
{
//Não estou usando o Repository Pattern
//E vou me permitir fazer isso na classe de cliente e não em um repositório
DummyDBContext<Cliente>.Salvar(this);
}

#endregion Public Methods
}
}[/csharp]

Quem é responsável por chamar as minhas estratégias é o “DummyDBContext“, ele se torna responsável por garantir que a estratégias será executada.

Vamos ver a implementação desta classe a seguir.

[csharp]/*
* Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de
validação ou regra ou se utiliza de algum framework.
*
* Iremos assumir que nossos objetos serão salvos por um contexto de base de dados.
* Cada linguagem ou ORM irá implementar de forma diferente.
*
*/

using Solid.Certo.Persistence.Contract;
using Solid.Certo.Strategy.Contract;
using System;
using System.Collections.Generic;

namespace Solid.Certo.Repository
{
/*
* Nesta classe a inversão acontece claramente, uma vez que a minha classe de acesso os
dados não sabe quem vai validar e nem como vai validar os dados que serão enviados ao banco de dados.
Ela simplesmente usa a interface de estratégia para achar a estratégia correto e realizar as validações necessárias.
*
*/
public static class DummyDBContext<TEntity>
where TEntity : class, IEntity
{
#region Private Methods

private static void Adicionar(TEntity entity)
{
Console.WriteLine($"A entidade {typeof(TEntity).Name} foi salva na base de dados.");
}

private static void Atualizar(TEntity entity)
{
Console.WriteLine($"A entidade {typeof(TEntity).Name} foi atualizada na base de dados.");
}

private static void EhValida(TEntity entity)
{
foreach(string item in RecuperarEstrategia(entity).Validar())
{
throw new Exception(item);
}
}

private static IPersistenceStrategy<TEntity> RecuperarEstrategia(TEntity entity)
{
IPersistenceStrategy<TEntity> result =
DependencyService.StrategyDependencyManager.RecuperarEstrategiaPersistencia(entity);
result.Entidade = entity;
return result;
}

#endregion Private Methods

#region Public Methods

public static void Salvar(TEntity entity)
{
EhValida(entity);
RecuperarEstrategia(entity).AntesDeSalvar(entity);

if(entity.Codigo > 0)
Atualizar(entity);
else
Adicionar(entity);

RecuperarEstrategia(entity).DepoisDeSalvar(entity);
}

public static IEnumerable<TEntity> Selecionar(long? id = null)
{
List<TEntity> result = new List<TEntity>();

foreach(TEntity item in result)
{
yield return item;
}

yield break;
}

#endregion Public Methods
}
}[/csharp]

Podemos perceber que a classe “DummyDBContext” não precisa conhecer as estratégias, nem as validações, nem o serviço de e-mail.
Isso é feito pela classe de serviço “DependencyService.StrategyDependencyManager” no método “RecuperarEstrategiaPersistencia“.

Cada framework ou contêiner de injeção irá fazer de uma forma, aqui estamos fazendo desta forma, pois não é o nosso foco usar qualquer framework de injeção de depêndencia.

Ok. Mas como devo implementar a estratégia para que ela faça a validação da minha classe antes de salvar.

Primeiro temos que implementar nosso serviço de injeção de depêndencia. Veja abaixo a classe “StrategyDependencyManager”.
Esta classe vai registrar as nossas estratégias no método “RegistrarEstrategias”.

[csharp]/*
* Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework.
*/

using Solid.Certo.Persistence.Contract;
using Solid.Certo.Strategy;
using Solid.Certo.Strategy.Contract;
using System.Collections.Generic;

namespace Solid.Certo.DependencyService
{
public static class StrategyDependencyManager
{
#region Private Fields

private static Dictionary<string, IStrategy> estrategias = new Dictionary<string, IStrategy>();

#endregion Private Fields

#region Public Methods

public static IPersistenceStrategy<TEntity>
RecuperarEstrategiaPersistencia<TEntity>(TEntity entity)
where TEntity : IEntity
{
return (IPersistenceStrategy<TEntity>)estrategias[entity.GetType().Name];
}

public static void RegistrarEstrategias()
{
//aqui eu mantive fixo, mas o correto é manter de forma dinâmica. (desacoplado)
//Estude como o seu framework de injeção de dependência trabalha para que se mantenha esta parte do código dinâmica (desacoplada)
//Não foi intuito deste exemplo de código mostrar nenhum contêiner ou framework de injeção de dependência.
estrategias[typeof(Persistence.Cliente).Name] = new ClienteStrategy();
estrategias[typeof(Persistence.Venda).Name] = new VendaStrategy();
}

#endregion Public Methods
}
}[/csharp]

Abaixo vemos a implementação da classe “ClienteStrategy“, responsável por garantir que os dados de clientes sejam salvos de acordo com a regra de cada customização.
Aqui podemos usar a compilação “On the Fly“; em tempo de execução; Ou usar o “Plugin Pattern” para a definição de novas regras de negócio.

Utilizamos um serviço de e-mail para o envio de e-mail ao cliente.
Utilizamos o “Validator Pattern“, de forma simples, para verificação do CNPJ.

[csharp]/*
* Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework.
*/

using Solid.Certo.Persistence;
using Solid.Certo.Service;
using Solid.Certo.Strategy.Abstract;
using Solid.Certo.Validator;
using System;
using System.Collections.Generic;
using System.Linq;

namespace Solid.Certo.Strategy
{

/*
* As classes de estratégia não conhecem a implementação do banco de dados,
apenas verificam se está tudo correto para que seja salvo em banco de dados.&lt;/pre&gt;
&lt;pre&gt; *
*/

//Sim, ao invés de "Cliente", podemos definir até aqui como sendo uma interface de cliente "ICliente".
public class ClienteStrategy: PersistenceStrategyBase<Cliente>
{
#region Public Constructors

public ClienteStrategy() : base()
{
}

#endregion Public Constructors

#region Public Methods

public override void DepoisDeSalvar(Cliente entity)
{
base.DepoisDeSalvar(entity);
//Podemos também injetar o serviço de envio de emails. Desta forma esta classe não precisaria nem conhecer o EmailService.
EmailService.EnviarEmail(entity.Email);
}

public override IEnumerable<string> Validar()
{
if(String.IsNullOrWhiteSpace(Entidade.Nome))
yield return "O nome é obrigatório";

if(!Entidade.Email.Contains("@"))
yield return "O e-mail não é válido";

//Aqui, para diminuir ainda mais o acoplamento.
//Usando injeção de dependência podemos definir o nosso validador de CNPJ,
//uma vez que o mesmo implementa a interface IValidator<>
//O que poderia ser customizado para cada cliente, por exemplo.
string cnpjEhValido = new CNPJValidator().Validar(Entidade.CNPJ).FirstOrDefault();

if(!String.IsNullOrEmpty(cnpjEhValido))
yield return cnpjEhValido;

yield break;
}

#endregion Public Methods
}
}[/csharp]

Até o momento vimos as classes principais da nossa inversão, sentimos o gostinho da injeção de depêndencia, definimos classes estáveis e instáveis.
Foi muito utilizado o Princípio da Substituição, abusamos de interfaces e abstrações.

Apesar da escrita de código parecer mais demorada, a manutenção em um código bem escrito é muito mais simples.
Escrever testes de unidade, se torna mais simples, pois podemos atacar apenas o ponto que precisamos garantir que tudo ocorra de acordo com as regras.

Abaixo, as demais classes utilizadas no projeto. Não menos importantes que as demais acima.

Interface de validação de campos, CNPJ, CPF entre outros.

[csharp]
/*
* Classe apenas para fins de exemplo e aprendizado
* não considera nenhum tipo de validação ou regra ou se utiliza de algum framework.
*/

using System.Collections.Generic;

namespace Solid.Certo.Validator.Contract
{
public interface IValidator<TValue>
{
#region Public Methods
//Retorna todos os erros ao validar o objeto
IEnumerable<string> Validar(TValue value);

#endregion Public Methods
}
}[/csharp]

Validação do CNPJ

[csharp]
/*
* Classe apenas para fins de exemplo e aprendizado não considera
* nenhum tipo de validação ou regra ou se utiliza de algum framework.
*/

using Solid.Certo.Validator.Contract;
using System.Collections.Generic;

namespace Solid.Certo.Validator
{
public class CNPJValidator: IValidator<string>
{
#region Public Methods

public IEnumerable<string> Validar(string value)
{
if((value?.Length ?? 0) != 14)
yield return "CNPJ não é válido.";

yield break;
}

#endregion Public Methods
}
}[/csharp]

Definição da inerface de estratégia de base

[csharp]/*
* Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework.
*/

using System.Collections.Generic;

namespace Solid.Certo.Strategy.Contract
{
public interface IStrategy
{
#region Public Methods

IEnumerable<string> Validar();

#endregion Public Methods
}
}[/csharp]

Definição de estrategia de persistência.

[csharp]/*
* Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework.
*/

using Solid.Certo.Persistence.Contract;

namespace Solid.Certo.Strategy.Contract
{
public interface IPersistenceStrategy<TEntity>: IStrategy
where TEntity : IEntity
{
#region Public Properties

TEntity Entidade { get; set; }

void DepoisDeSalvar(TEntity entity);

void AntesDeSalvar(TEntity entity);

#endregion Public Properties
}
}[/csharp]

Abstração para a estratégia de base.

[csharp]using Solid.Certo.Strategy.Contract;
using System.Collections.Generic;

namespace Solid.Certo.Strategy.Abstract
{
public abstract class StrategyBase: IStrategy
{
#region Public Methods

public abstract IEnumerable<string> Validar();

#endregion Public Methods
}
}[/csharp]

Abstração para definição da estratégia de peristência.

[csharp]/*
* Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework.
*/

using Solid.Certo.Persistence.Contract;
using Solid.Certo.Strategy.Contract;

namespace Solid.Certo.Strategy.Abstract
{
public abstract class PersistenceStrategyBase<TEntity>: StrategyBase, IPersistenceStrategy<TEntity>
where TEntity : class, IEntity, new()
{
#region Protected Constructors

protected PersistenceStrategyBase()
{
}

#endregion Protected Constructors

#region Public Properties

public TEntity Entidade { get; set; }

#endregion Public Properties

#region Public Methods

public virtual void AntesDeSalvar(TEntity entity)
{
//na classe de base eu não faço nada
}

public virtual void DepoisDeSalvar(TEntity entity)
{
//na classe de base eu não faço nada
}

#endregion Public Methods
}
}[/csharp]

Conclusão

Com isso, terminamos a série de artigos sobre S.O.L.I.D. Claro, que o assunto pode se estender mais. As classes acima podem sofrer modificações dependendo do framework utilizado ou do pattern escolhido para desenvolvimento.

Como tudo em excesso faz mal. O uso excessivo de IoC (Inversão de controles) e DI (Injeção de dependência) pode levar à um código extremamente complexo e de difícil entendimento. Existem programadores que sofrem de “Patternite”, quer dizer que não pode ver um pattern que já quer inserir no desenvolvimento da aplicação.
O uso excessivo pode causar até mesmo lentidão na execução da aplicação. Para se fazer uma simples tela, tem que se desenvolver cinco camadas, dois factories, um listener/ observable.

É! Eu me permito ferir, só um pouco, uma classe, quando tenho certeza de que esta classe não irá se corromper com o tempo. (Eu nunca disse isso).

O fonte utilizado aqui pode ser baixado pelo GITHub em https://github.com/desenvolvedores-net/ArtigoSOLID

É isso ai pessoal 🙂
Até o próximo
♦ Marcelo

Veja o índice completo do tópico “S.O.L.I.D”

Olá pessoas …

Continuando a nossa saga de artigos, vamos agora ver a letra I do acróstico que define a sigla ISP Interface Segregation Principle (Princípio de Segregação de Interface).

Definição

Este princípio é o mais simples de entender, ele quer dizer que:

Classes clientes não devem ser forçadas a depender de métodos que elas não usam Mas eu prefiro dizer que: As abstrações não dependem de detalhes, mas os detalhes dependem de abstrações. Evite o uso de interfaces gordas, assim como devemos evitar o uso de classes ou objetos deuses.

A segregação de interfaces assume que suas interfaces devem ser coesas, quando uma interface não é coesa, ele contêm métodos que não dizem respeito ao grupo de comportamento que as definem.

Coesão está diretamente ligada ao Princípio da Responsabilidade Única (SRP).

Certo ou errado? Vamos agora aos nossos exemplos entre certo e errado.

Ferindo o princípio

Isto está errado. Perceba que a interface “ISaldo” define o método “Atualizar()” e o método “BaixarEstoque()“. A primeira vista está certo, pois podemos assumir que é uma interface para cálculo de saldo de estoques. [csharp] /* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ namespace Solid.Errado.Contract { public interface ISaldo { #region Public Methods void Atualizar(); void BaixarEstoque(); #endregion Public Methods } } [/csharp] A classe abaixo, de forma errada e ferindo o princípio da SRP, implementa a interface “ISaldo“, perceba que a classe de saldo é obrigada a atualizar os saldos e realizar a baixa em estoque de um produto qualquer. [csharp] /* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ using Solid.Errado.Contract; using System; namespace Solid.Errado { public class AtualizarSaldoDiario: ISaldo { #region Public Methods public void Atualizar() { Console.WriteLine("O saldo DIARIO foi atualizado."); } public void BaixarEstoque() { Console.WriteLine("O estoque foi baixado em 10 itens"); Atualizar(); } #endregion Public Methods } } [/csharp] Classe para cálculo de saldo financeiro. [csharp] /* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ using Solid.Errado.Contract; using System; namespace Solid.Errado { public class SaldoFinanceiro: ISaldo { #region Public Methods public void Atualizar() { Console.WriteLine("O saldo financeiro foi atualizado."); } public void BaixarEstoque() { throw new Exception("OPS! Eu não sei o que fazer aqui. Não sou uma classe de saldo de estoques"); } #endregion Public Methods } } [/csharp]

Como podemos perceber, à primeira vista nossas definições de interfaces parecem corretas, pois se estamos falando de saldos, podemos baixar o estoque para calcular os saldos. Neste momento já podemos perceber que ferimos o princípio do SRP e do ISP.  Apesar de eu estar falando de saldos, eu posso estar calculando saldos financeiros, que nada têm haver com saldos de estoque, e se por alguma razão eu implementar esta definição de saldos, serei obrigado a baixar estoque em uma movimentação financeira.

Então, vamos corrigir o princípio…

Corrigindo o princípio

Isto está correto. Definição de contratos (Interfaces) [csharp] namespace Solid.Certo.ISP.Contract { public interface ISaldo { #region Public Methods #region Public Methods void Atualizar(); #endregion Public Methods } } [/csharp] [csharp] namespace Solid.Certo.ISP.Contract { public interface ISaldoEstoque: ISaldo { } } [/csharp] [csharp] namespace Solid.Certo.ISP.Contract { public interface ISaldoFinanceiro: ISaldo { } } [/csharp] Definição de abstrações [csharp] using Solid.Certo.ISP.Contract; namespace Solid.Certo.ISP.Abstract { public abstract class SaldoBase: ISaldo { #region Public Methods public abstract void Atualizar(); #endregion Public Methods } } [/csharp] [csharp] using System; using Solid.Certo.ISP.Contract; namespace Solid.Certo.ISP.Abstract { public abstract class SaldoEstoqueBase: SaldoBase, ISaldoEstoque { public override void Atualizar() { Console.WriteLine("Saldo de estoque atualizado."); } } } [/csharp] [csharp] using System; using Solid.Certo.ISP.Contract; namespace Solid.Certo.ISP.Abstract { public abstract class SaldoFinanceiroBase: SaldoBase, ISaldoFinanceiro { #region Public Methods public override void Atualizar() { Console.WriteLine("O saldo financeiro foi atualizado."); } #endregion Public Methods } } [/csharp] Classes concretas [csharp] using Solid.Certo.ISP.Abstract; namespace Solid.Certo.ISP { public class SaldoEstoque: SaldoEstoqueBase { } } [/csharp] [csharp] using Solid.Certo.ISP.Abstract; namespace Solid.Certo.ISP { public class SaldoFinanceiro: SaldoFinanceiroBase { } }[/csharp]

Como podemos perceber, ao extrair as interfaces, abstrações e definindo as classes concretas, utilizamos os 4 princípios que aprendemos até agora:

•  Cada uma tem sua responsabilidade, (SRP);
  • As classes de saldo, só atualizam saldos. Removemos o a baixa de estoque da interface mais genérica.
• Podem sofrer heranças e ter seus comportamentos modificados, (OCP);
  • Eu posso herdar a classe de saldos de base e modificar o comportamento do método “Atualizar()“.
• Podem ser convertidas entre suas generalizações e especializações (LSP);
  • Eu posso passar, como parâmetro por exemplo, qualquer classe de saldo e chamar um método que realiza os cálculos de saldos da aplicação.
• E por fim, interfaces e abstrações (Este princípio – ISP);
  • Abstraímos todas as interfaces e abstrações das classes que necessitamos para que nossas classes de cálculo de saldos façam apenas cálculos de saldos.

O fonte utilizado aqui pode ser baixado pelo GITHub em https://github.com/desenvolvedores-net/ArtigoSOLID

É isso ai pessoal 🙂
Até o próximo
♦ Marcelo

Veja o índice completo do tópico “S.O.L.I.D”

Olá pessoas …

Continuando a nossa saga de artigos, vamos agora ver a letra L do acróstico que define a sigla LSP Liskov Substitution Principle (Princípio da Substituição de Liskov).

Definido o LSP

Não tem como falar deste princípio sem saber quem o criou, Barbara Liskov, em 1988.

A definição mais usada, e a mais simples, é:

Classes derivadas podem ser substituídas por suas classes de base. Se q(x) é uma propriedade demonstrável dos objetos x de tipo T. Então q(y) deve ser verdadeiro para objetos y de tipo S onde S é um subtipo de T. Portanto, a visão de “subtipo” defendida por Liskov é baseada na noção da substituição; isto é, se S é um subtipo de T, então os objetos do tipo T, em um programa, podem ser substituídos pelos objetos de tipo S sem que seja necessário alterar as propriedades deste programa. (fonte: Wikipédia)

Certo ou errado? E lá vamos nós novamente ver como fica o princípio ferido, os problemas que nos trazem e a solução do mesmo …

 Ferindo o princípio

Isto está errado. Utilitário de atualização de saldos. [csharp] /* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ using Solid.Errado.LSP.Abstract; namespace Solid.Errado.LSP { public static class AtualizarSaldo { #region Public Methods public static void AtualizarSaldos(params AtualizaSaldoBase[] saldos) { foreach(var saldo in saldos) { if(saldo is AtualizarSaldoAnual) ((AtualizarSaldoAnual)saldo).AtualizarAno(); else if(saldo is AtualizarSaldoMensal) ((AtualizarSaldoMensal)saldo).AtualizarMes(); else if(saldo is AtualizarSaldoDiario) ((AtualizarSaldoDiario)saldo).AtualizarDia(); } } #endregion Public Methods } } [/csharp] Abstração para as classes de saldo concretas [csharp] /* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ namespace Solid.Errado.LSP.Abstract { public abstract class AtualizaSaldoBase { #region Public Properties public double SaldoAtual { get; set; } #endregion Public Properties } } [/csharp] Cálculo de saldo diário [csharp] /* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ using Solid.Errado.LSP.Abstract; using System; namespace Solid.Errado.LSP { public class AtualizarSaldoDiario: AtualizaSaldoBase { #region Public Methods public void AtualizarDia() { Console.WriteLine("O saldo DIARIO foi atualizado."); } #endregion Public Methods } } [/csharp] Cálculo de saldo mensal [csharp] /* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ using Solid.Errado.LSP.Abstract; using System; namespace Solid.Errado.LSP { public class AtualizarSaldoMensal: AtualizaSaldoBase { #region Public Methods public void AtualizarMes() { Console.WriteLine("O saldo MENSAL foi atualizado."); } #endregion Public Methods } } [/csharp] Cálculo de saldo anual [csharp] /* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ using Solid.Errado.LSP.Abstract; using System; namespace Solid.Errado.LSP { public class AtualizarSaldoAnual: AtualizaSaldoBase { #region Public Methods public void AtualizarAno() { Console.WriteLine("O saldo ANUAL foi atualizado."); } #endregion Public Methods } } [/csharp]

Problemas ao ferir o princípio

• Primeiro, já matamos o polimorfismo. Na classe de atualização de saldos “public static class AtualizarSaldo” no método “public static void AtualizarSaldos(params AtualizaSaldoBase[] saldos)” temos que fazer “if/else” para determinar que tipo de classe iremos usar para calcular o saldo.
• Na mesma classe citada acima, mesmo que utilizado a herança nas demais classes de atualização de saldo, eu não consigo o reaproveitamento do código de atualização de saldos, uma vez que eu tenho que identificar qual o tipo de classe e determinar o método que é chamado, veja no fragmento abaixo o “if/else”.

[csharp]
if(saldo is AtualizarSaldoAnual)
((AtualizarSaldoAnual)saldo).AtualizarAno();
else if(saldo is AtualizarSaldoMensal)
((AtualizarSaldoMensal)saldo).AtualizarMes();
else if(saldo is AtualizarSaldoDiario)
((AtualizarSaldoDiario)saldo).AtualizarDia();
[/csharp]

• Violação do princípio OCP
• Dar manutenção neste código é ter dores de cabeça, uma vez que teremos que lembrar de alterar este método de cálculo de saldos sempre que um novo tipo de saldo for criado.

Corrigindo o princípio

Como o LSP anda de mãos dadas com o OCP, podemos perceber que as classes de saldos definidos no princípio OCP atendem 100% os requisitos deste princípio . Vamos relembrar estas classes:

Isto está correto. Veja as classes que foram criadas: Abstração para os saldos, desta forma eu posso herdar minha classe principal e modificar apenas  o que eu preciso. [csharp] /* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ namespace Solid.Certo.Utility.Abstract { public abstract class AtualizaSaldoBase { #region Public Methods public abstract void Atualizar(); #endregion Public Methods } } [/csharp] Classe concreta de atualização de saldos diários. [csharp] /* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ using Solid.Certo.Utility.Abstract; using System; namespace Solid.Certo.Utility { public class AtualizaSaldoDiario: AtualizaSaldoBase { #region Public Methods public override void Atualizar() { Console.WriteLine("O saldo DIÁRIO foi atualizado."); } #endregion Public Methods } } [/csharp] Classe concreta de atualização de saldos mensais. [csharp] /* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ using Solid.Certo.Utility.Abstract; using System; namespace Solid.Certo.Utility { public class AtualizaSaldoMensal: AtualizaSaldoBase { #region Public Methods public override void Atualizar() { Console.WriteLine("O saldo MENSAL foi atualizado."); } #endregion Public Methods } } [/csharp] Classe concreta de atualização de saldos anuais. [csharp] /* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ using Solid.Certo.Utility.Abstract; using System; namespace Solid.Certo.Utility { public class AtualizaSaldoAnual: AtualizaSaldoBase { #region Public Methods public override void Atualizar() { Console.WriteLine("O saldo ANUAL foi atualizado."); } #endregion Public Methods } } [/csharp] Classe de serviço para atualização de saldos no estoque. [csharp] /* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ using Solid.Certo.Utility.Abstract; using System.Collections.Generic; namespace Solid.Certo.Service { public static class AtualizaSaldoService { #region Public Methods public static void AtualizarSaldos(List<AtualizaSaldoBase> saldos) { foreach(AtualizaSaldoBase saldo in saldos) { saldo.Atualizar(); } } #endregion Public Methods } } [/csharp]

Analisando as classes definidas acima, podemos perceber que:

• As classes de saldo herdam diretamente da classe “public abstract class AtualizaSaldoBase”;
• Passamos a ter acesso ao método “Atualizar()”, desta forma eu consigo chamar o método “Atualizar()” a partir da classe mais genérica (Veja: Generalização e Especialização), é utilizado o polimorfismo para evitar o uso de “if/ else”, como podemos ver no fragmento abaixo da classe de serviço de atualização de saldo.

[csharp highlight=”9″]
public static class AtualizaSaldoService
{
#region Public Methods

public static void AtualizarSaldos(List<AtualizaSaldoBase> saldos)
{
foreach(AtualizaSaldoBase saldo in saldos)
{
saldo.Atualizar();
}
}

#endregion Public Methods
}
[/csharp]

• Se necessário criar um novo tipo de saldo, basta criar a classe, herdar de “AtualizaSaldoBase” e implementar a chamada onde queremos que o novo saldo seja calculado sem termos que nos preocupar em fazer “if” para identificar o tipo de  saldo que iremos calcular;
• A classe mais especializada pode ser facilmente convertida na classe mais genérica e atende ao princípio em questão;

Pegadinha e cuidados

Que diabos O patinho feio; história infantil; está fazendo aqui? Ora! É simples. Se nada como um pato, tem as habilidades de um pato, come igual ao pato mas é um marreco cisne, então você tem um problema de abstração.

Vamos ao exemplo mais clássico de erro de abstração Quadrado x Retângulo. Não poderíamos falar de LSP sem comentar sobre o Quadrado x Retângulo.

Todo quadrado é também um retângulo, pois ambos tem ângulos retos. Mas nem todo retângulo é um quadrado. Quem me disse foi o Professor Procópio do Matemática Rio, no vídeo Qual a Diferença entre Retângulo e Quadrado?

Vamos aos fontes:

Classe de retângulo.

[csharp]
/*
* Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework.
*/

namespace Solid.Errado.QuadradoRetangulo
{
public class Retangulo
{
#region Public Properties

public virtual int Altura { get; set; }
public virtual int Largura { get; set; }

#endregion Public Properties
}
}

[/csharp]

Classe do quadrado que herda de retângulo (Já falei sobre herança?)

[csharp]
/*
* Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework.
*/

namespace Solid.Errado.QuadradoRetangulo
{
public class Quadrado: Retangulo
{
}
}
[/csharp]

Utilitário para cálculo de área.

[csharp]
/*
* Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework.
*/

using Solid.Errado.QuadradoRetangulo;

namespace Solid.Errado.Utility
{
public static class CalculaArea
{
#region Public Methods

//Sim, este método poderia ser da classe retângulo.
//Mas para efeito de exemplo, vou deixar ele aqui.
public static int CalcularArea(Retangulo retangulo)
{
return retangulo.Altura * retangulo.Largura;
}

#endregion Public Methods
}
}
[/csharp]

Chamada de exemplo para ambos os casos

[csharp]
int altura;
int largura;

Console.WriteLine("\r\nInforme a altura:");
altura = Convert.ToInt32(Console.ReadLine());
Console.WriteLine("Informe a largura:");
largura = Convert.ToInt32(Console.ReadLine());

//aqui, podemos criar um quadrado normalmente.
Quadrado quadrado = new Quadrado
{
Altura = altura,
Largura = largura
};

//aqui, criamos um retângulo com base em um quadrado, atendendo ao princípio do LSP
Retangulo retanguloQuadrado = new Quadrado
{
Altura = altura,
Largura = largura
};

//Aqui criamos um retângulo normalmente.
Retangulo retangulo = new Retangulo
{
Altura = altura,
Largura = largura
};

int quadradoAreaEsperada = altura * altura;
int retanguloAreaEsperada = largura * altura;
//o método CalcularArea() espera um retângulo, perceba que podemos passar tanto um quadrado quanto um retângulo. Atendendo ao princípio LSP.
Console.WriteLine($"A área correta do retângulo é {retanguloAreaEsperada} e a calculada foi {Errado.Utility.CalculaArea.CalcularArea(retangulo)}");
Console.WriteLine($"A área correta do quadrado é {quadradoAreaEsperada} e a calculada foi {Errado.Utility.CalculaArea.CalcularArea(quadrado)}");
[/csharp]

Vamos analisar os fontes e explicar o real problema de não tomarmos cuidado no momento de definirmos nossas abstrações.

As classes definidas, a primeira vista, não ferem o princípio LSP, uma vez que podem ser herdadas, terem seus métodos sobrescritos, são reutilizáveis e eu posso criar a mais genérica pela classe mais especializada, posso utilizar a classe mais genérica como parâmetro e passar a mais especializada, como diz o princípio da substituição.
No caso, como foi mostrado, eu posso criar um retângulo a partir de um quadrado. Veja o fragmento abaixo

[csharp]
//aqui, criamos um retângulo com base em um quadrado, atendendo ao princípio do LSP
Retangulo retanguloQuadrado = new Quadrado
{
Altura = altura,
Largura = largura
};
[/csharp]

Mas isso, tem um erro. Imagina que nossos sistema é usado para calcular as esquadrias em um prédio. E neste sistema eu preciso calcular a área para pedir que se corte uma esquadria quadrada. considerando que o quadrado tem seus lados iguais, e meu sistema aceita que eu passe altura x largura diferentes, mesmo para a classe “Quadrado”, eu tenho um erro de regra de negócio e de abstração.

Se eu crio uma classe retângulo a partir de uma classe “Quadrado” a área calculada ficará errada se eu passar os valores de “Altura” e “Largura” diferentes.

[csharp]
//aqui, criamos um retângulo com base em um quadrado, atendendo ao princípio do LSP
Retangulo retanguloQuadrado = new Quadrado
{
Altura = 10,
Largura = 5
};

//aqui acontece o erro, uma vez que eu passei 10×5=50. O meu calculo de área deveria considerar Altura X Largura igual para o calculo de quadrados.
Console.WriteLine($"A área correta do quadrado é {Errado.Utility.CalculaArea.CalcularArea(retanguloQuadrado)}");
[/csharp]

Pegando um exemplo real, nos artigos anteriores temos tratado as nossas classes de saldos como saldos de estoque. Imaginem que eu queira calcular o saldo financeiro. Em sua essência o cálculo é igual um menos o outro, entradas menos saídas. Só que de um lado eu estou falando de produtos, e de outro de valores monetários, cada qual com suas regras específicas.

Para terminar

Para atender ao princípio de Liskov, temos que garantir que as nossa classes genéricas, sejam substituíveis pelas nossas classes especializadas; Veja: Generalização x Especialização; Desta forma atendemos também o OCP.

Cuidado ao usar o princípio “É UM”, e preste muita atenção que este princípio se aplica ao comportamento da classe e não aos tipos ou subtipos. Valorize o polimorfismo.

Para saber mais. Herança; Polimorfismo; Generalização e Especialização; Tipos Genéricos;

O fonte utilizado aqui pode ser baixado pelo GITHub em https://github.com/desenvolvedores-net/ArtigoSOLID

É isso ai pessoal 🙂
Até o próximo
♦ Marcelo

Veja o índice completo do tópico “S.O.L.I.D”

Olá pessoas …

Continuando a nossa saga de artigos, vamos agora ver a letra O do acróstico, que define a sigla OCP Open/Closed Principle (Princípio aberto/ fechado).

Definindo OCP

Momento piadinha infame do artigo

Não iremos falar sobre o Robocop, mas toda vez que eu falo a sigla  OCP (Omni Consumer Products) eu vejo o Robocop na minha mente

Bom, vamos ao que interessa…

Você deve ser capaz de estender um comportamento de uma classe sem modificá-lo.

Esta declaração quer dizer que você tem que escrever suas classes de forma que elas possam ser herdadas e ter seu comportamento estendido ao invés de alterar o código existente. Para fazer isso, iremos usar o que chamamos de herança e abstração.

Para saber mais. Caso não esteja familiarizado com os termos herança e abstração, dê uma lida no artigo sobre “Herança”  e no artigo sobre “Abstração“. Tenho certeza que suas dúvidas serão sanadas.

Problemas em ferir o princípio OCP

• Reaproveitamento de código é praticamente nulo. CTRL+C/ CTRL+V, não é reaproveitamento de código;
• As classes podem fazer partes de componentes espalhados pela aplicação;
• O que acontece se precisarmos de uma nova implementação?
  • Colocamos mais um if/else if, um switch…case ?
  • Criamos uma nova classe e copiamos o código?
• Recompilar e fazer deploy em todos os componentes impactados;

Espero que você tenha um bom caso de testes escrito para cada situação.

Certo ou errado? Abaixo vou colocar os códigos “ERRADO” e “CERTO” e ao final, analisar cada um.

Ferindo o OCP

Isto está errado. Primeiro, vamos criar nossa classe de venda para atender as vendas da nossa aplicação. [csharp]/* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ using System; using System.Collections.Generic; namespace Solid.Errado { public class Venda { #region Public Properties public int Codigo { get; set; } public int CodigoCliente { get; set; } public List<string> Itens { get; set; } public double TotalVenda { get; set; } #endregion Public Properties #region Public Methods public void Salvar() { Validar(); Console.WriteLine("A venda foi salva."); CalcularTotal(); AtualizarSaldo(); } private void CalcularTotal() { Console.WriteLine("O total da venda foi calculado."); } public void Validar() { if(CodigoCliente == 0) throw new Exception("O código do cliente é obrigatório."); if((Itens?.Count ?? 0) == 0) throw new Exception("A quantidade de itens vendida não pode ser zero."); } public void AtualizarSaldo() { Utility.AtualizarSaldo.AtualizarSaldos(new AtualizarSaldoAnual(), new AtualizarSaldoMensal(), new AtualizarSaldoDiario()); } #endregion Public Methods } }[/csharp] Com a classe de vendas criada, precisamos atualizar os saldos de estoque, pois a venda faz uma saída em nossos produtos. Esta classe é um utilitário de atualização de saldos de estoque, e recebe objetos para realizar os cálculos de saldo de estoque. [csharp] /* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ namespace Solid.Errado.Utility { public static class AtualizarSaldo { #region Public Methods public static void AtualizarSaldos(params object[] saldos) { foreach(var saldo in saldos) { if(saldo.GetType() == typeof(AtualizarSaldoAnual)) ((AtualizarSaldoAnual)saldo).Atualizar(); else if(saldo.GetType() == typeof(AtualizarSaldoMensal)) ((AtualizarSaldoMensal)saldo).Atualizar(); else if(saldo.GetType() == typeof(AtualizarSaldoDiario)) ((AtualizarSaldoDiario)saldo).Atualizar(); } } #endregion Public Methods } } [/csharp] E abaixo, as classes de atualização de saldo diário, mensal e anual. Saldo Diário [csharp] /* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ using System; namespace Solid.Errado { public class AtualizarSaldoDiario { #region Public Methods public void Atualizar() { Console.WriteLine("O saldo DIARIO foi atualizado."); } #endregion Public Methods } } [/csharp] Saldo Mensal [csharp] /* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ using System; namespace Solid.Errado { public class AtualizarSaldoMensal { #region Public Methods public void Atualizar() { Console.WriteLine("O saldo MENSAL foi atualizado."); } #endregion Public Methods } } [/csharp] Saldo Anual [csharp] /* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ using System; namespace Solid.Errado { public class AtualizarSaldoAnual { #region Public Methods public void Atualizar() { Console.WriteLine("O saldo ANUAL foi atualizado."); } #endregion Public Methods } } [/csharp]

Logo de cara já percebemos que a classe de vendas fere completamente o Princípio da Responsabilidade Única, ela se “valida”, ele atualiza os saldos de estoque entre outros problemas que você já é capaz de identificar com a leitura do primeiro artigo.

Mas o que realmente nos interessa aqui, são as classes de saldos. Estas ferem completamente o princípio OCP (Aberto/ Fechado).

• Mesmo que eu faça a herança destas classes, por exemplo, para criar um saldo quinzenal, eu não consigo substituir o comportamento do método atualizar;
• O utilitário de atualização de saldos, classe “Utility.AtualizarSaldo“, tem que conhecer as classes de saldos e fazer um “if” para identificar qual é o tipo de saldo que deverá ser atualizado;
  • Se eu precisar implementar mais um tipo de saldo, tenho que lembrar deste “if” e criar um método com o mesmo nome “Atualizar” para manter um mínimo de padrão;
  • Este utilitário aceita tipos “object“, isso quer dizer que se eu passar uma classe errada para o meu método, posso ter um erro em tempo de execução, ou não ter meus saldos de estoque calculados corretamente;
• Percebemos que não houve reaproveitamento de código entre as classes de saldos;

Corrigindo o princípio

Neste momento, iremos corrigir o princípio e ao final analisar as modificações que foram realizadas para atender ao princípio do OCP.

Isto está correto. Veja as classes que foram criadas: Classe de venda para realização das vendas em nosso estabelecimento. [csharp] /* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ using Solid.Certo.Persistence.Abstract; using Solid.Certo.Repository; using System.Collections.Generic; namespace Solid.Certo.Persistence { public class Venda: EntityBase { #region Public Properties public int CodigoCliente { get; set; } public List<string> Itens { get; set; } public double TotalVenda { get; set; } #endregion Public Properties #region Public Methods public override void Salvar() { DBContext<Venda>.Salvar(this); } #endregion Public Methods } } [/csharp] Abstração para os saldos, desta forma eu posso herdar minha classe principal e modificar apenas  o que eu preciso. [csharp] /* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ namespace Solid.Certo.Utility.Abstract { public abstract class AtualizaSaldoBase { #region Public Methods public abstract void Atualizar(); #endregion Public Methods } } [/csharp] Classe concreta de atualização de saldos diários. [csharp] /* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ using Solid.Certo.Utility.Abstract; using System; namespace Solid.Certo.Utility { public class AtualizaSaldoDiario: AtualizaSaldoBase { #region Public Methods public override void Atualizar() { Console.WriteLine("O saldo DIÁRIO foi atualizado."); } #endregion Public Methods } } [/csharp] Classe concreta de atualização de saldos mensais. [csharp] /* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ using Solid.Certo.Utility.Abstract; using System; namespace Solid.Certo.Utility { public class AtualizaSaldoMensal: AtualizaSaldoBase { #region Public Methods public override void Atualizar() { Console.WriteLine("O saldo MENSAL foi atualizado."); } #endregion Public Methods } } [/csharp] Classe concreta de atualização de saldos anuais. [csharp] /* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ using Solid.Certo.Utility.Abstract; using System; namespace Solid.Certo.Utility { public class AtualizaSaldoAnual: AtualizaSaldoBase { #region Public Methods public override void Atualizar() { Console.WriteLine("O saldo ANUAL foi atualizado."); } #endregion Public Methods } } [/csharp] Estratégia de venda, responsável pela nossa regra de negócio quando a venda for realizada. [csharp] /* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ using Solid.Certo.Persistence; using Solid.Certo.Strategy.Abstract; using Solid.Certo.Utility.Abstract; using System; using System.Collections.Generic; namespace Solid.Certo.Strategy { public class VendaStrategy: PersistenceStrategyBase<Venda> { #region Public Methods public override void AntesDeSalvar(Venda entity) { base.AntesDeSalvar(entity); //vamos simular uma cálculo de total de venda Entidade.TotalVenda = 30; Console.WriteLine("O total da venda foi calculado"); } public override IEnumerable<string> Validar() { if(Entidade.CodigoCliente == 0) yield return "O código do cliente é obrigatório."; if((Entidade.Itens?.Count ?? 0) == 0) yield return "A quantidade de itens vendida não pode ser zero."; yield break; } public override void DepoisDeSalvar(Venda entity) { base.DepoisDeSalvar(entity); Service.AtualizaSaldoService.AtualizarSaldos(new List<AtualizaSaldoBase> { new Utility.AtualizaSaldoDiario(), new Utility.AtualizaSaldoMensal(), new Utility.AtualizaSaldoAnual() }); } #endregion Public Methods } } [/csharp] Classe de serviço para atualização de saldos no estoque. [csharp] /* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ using Solid.Certo.Utility.Abstract; using System.Collections.Generic; namespace Solid.Certo.Service { public static class AtualizaSaldoService { #region Public Methods public static void AtualizarSaldos(List<AtualizaSaldoBase> saldos) { foreach(AtualizaSaldoBase saldo in saldos) { saldo.Atualizar(); } } #endregion Public Methods } } [/csharp]

Como podemos ver, até a classe de vendas foi corrigida. Não fere mais  o primeiro princípio.

Como o foco foram as classes de saldos, iremos listar as vantagens desta abordagem.

• Com o uso da abstração; (clique para saber mais sobre Abstração); conseguimos isolar os métodos comuns das nossas classes de cálculo de saldos;
• Fizemos com que as classes filhas, implementassem o método “Atualizar” para que cada uma saiba como fazer a atualização de saldos em estoque;
• As estratégias indicam o momento em que a atualização dos saldos devem ocorrer;
• Se for necessário a inclusão do saldo quinzenal, basta apenas criar a classe e inserir na estratégia o momento em que se deseja atualizar o saldo;
• Não é necessário fazer o uso de “if/else if” ou “switch…case” no momento da atualização de saldos, isso foi resolvido com o Polimorfismo;
  • Perceba que ao utilizar a abstração para chamar a atualização de  saldos, nos não precisamos mais nos preocupar em fazer “if/else if” e nem se preocupar se o tipo de objeto passado é do tipo saldo. Uma vez que a herança; (clique para saber mais sobre Herança) me permite fazer isto de forma transparente e garante que o tipo passado é do tipo saldo;
• E se necessário fazer uma customização para determinado cliente, podemos usar e abusar do padrão “Strategy“.

O fonte utilizado aqui pode ser baixado pelo GITHub em https://github.com/desenvolvedores-net/ArtigoSOLID

É isso ai pessoal 🙂
Até o próximo
♦ Marcelo