Tag design

Tell, don’t ask

Robson Castilho 4 Comentários

“Tell, don’t ask” é uma das práticas mais importantes da orientação a objetos, pois tem por maior objetivo reforçar a ideia de encapsulamento, conceito fundamental desse paradigma.

O nome vem do fato de que devemos dizer (tell) ao objeto o que fazer ao invés de perguntarmos (ask) ao objeto sobre seu estado e tomarmos alguma decisão.

Vamos a um exemplo onde “Tell, don’t ask” não é aplicado:

// ---- código-consumidor do objeto "carro" ----

carro.AcelerarPara(150);
// violando o "Tell, don't ask"
if (carro.VelocidadeAtual > carro.VelocidadeMaxima)
    throw new Exception("Velocidade superior à velocidade máxima!");

Continue lendo »

Anúncios

[Conceitos] Command-Query Separation (CQS)

Robson Castilho 10 Comentários

Blz, pessoal?

Retornando com mais um conceito neste post curto. Desta vez, falarei sobre o Command-Query Separation (CQS), princípio proposto por Bertrand Meyer.

Este princípio diz que um método pode ser um comando ou uma query, mas nunca ambos.

Um comando é um método que altera o estado do objeto que o define, não retornando nenhum valor:

public void AlterarEndereco(Endereco novoEndereco)
{
    this.endereco = novoEndereco;
}

Já uma query retorna algum resultado sem alterar o estado do objeto que a define. Em outras palavras, queries são funções livres de efeitos colaterais (side-effect-free functions):

public double CalcularMedia()
{
    return (this.X + this.Y) / 2;
}

Seguindo essa guideline, seus métodos ficam mais claros e com um único objetivo (o Princípio da Responsabilidade Única também deve ser considerado em métodos).

Além disso, eles passam a ser mais confiáveis. Uma query pode ser chamada mais de uma vez em sequência sem resultados indesejados. Outra forma de pensar sobre isso é que “uma query responde uma pergunta e responder uma pergunta não pode alterar a resposta”.

Portanto, vale a pena considerar esse princípio ao escrevermos nosso código.

Já consideraram? Quais os exemplos mais comuns que quebram esse princípio?

Até a próxima!

Princípios SOLID: Princípio da Inversão de Dependência (DIP)

Robson Castilho 29 Comentários

Olá, galera

Chegamos, enfim, ao último post da série sobre os cinco princípios SOLID, o qual abordará o Princípio da Inversão de Dependência (Dependency Inversion Principle), ou simplesmente DIP.

O DIP é base para um bom design orientado a objetos e extremamente importante para o projeto de uma arquitetura de software flexível e focada no domínio.

Então vamos ao que interessa. Continue lendo »

Princípios SOLID: Princípio da Segregação de Interface (ISP)

Robson Castilho 17 Comentários

Olá, galera

Continuando a série sobre os princípios SOLID, chegamos ao quarto princípio, conhecido por Princípio da Segregação de Interface (Interface Segregation Principle), ou simplesmente ISP.

Se você está chegando agora, lembro que os princípios SOLID são boas práticas de OO que ajudam a melhorar o design de nossas classes, removendo design smells e, por consequência, tornando o software mais fácil de ser mantido. Recomendo também a leitura dos posts anteriores sobre [SRP], [OCP] e [LSP].

Vamos então ao ISP. Continue lendo »

Princípios SOLID: Princípio de Substituição de Liskov (LSP)

Robson Castilho 20 Comentários

Olá, povo!

De volta aos princípios SOLID com o terceiro princípio do acrônimo: o Princípio de Substituição de Liskov (Liskov Substitution Principle), ou simplesmente LSP. Recomendo que leiam os 2 posts anteriores da série <aqui> e <aqui>, principalmente o post sobre o OCP, que está diretamente relacionado a este.

Vamos lá então!

DEFINIÇÃO

O Princípio de Substituição de Liskov leva esse nome por ter sido criado por Barbara Liskov, em 1988 (você pensou que algum “liskov” seria substituído é?).

Sua definição mais usada diz que:

“Classes derivadas devem poder ser substituídas por suas classes base”

Que é uma forma mais simples de explicar a definição formal de Liskov:

“Se para cada objeto o1 do tipo S há um objeto o2 do tipo T de forma que, para todos os programas P definidos em termos de T, o comportamento de P é inalterado quando o1 é substituído por o2 então S é um subtipo de T”

Continue lendo »