Design Orientado a Objetos: Princípios e Padrões (1a Ed)

Realizarei nos dias 24/09/2016 e 01/10/2016, o treinamento “Design Orientado a Objetos: Princípios e Padrões”, com um enfoque mais aprofundado em POO, discutindo diversos princípios e padrões, de forma a utilizar a POO de forma mais efetiva e com maior qualidade.

O treinamento será PRESENCIAL, aqui em Campo Grande/MS. Mais informações, vocês encontram na página do mesmo: http://eventick.com.br/oopp/

São apenas 9 vagas! Agradeço a quem puder divulgar!

Para quaisquer informações que não estejam na página, como, por ex, realização in-company, entrem em contato: falecom@robsoncastilho.com.br

Anúncios

Deixando seus testes mais legíveis e robustos

É muito comum, ao iniciar com a escrita de testes automatizados, não tomarmos certas precauções, fazendo com que a leitura e a manutenção dos mesmos se tornem um pesadelo. Acabamos vendo testes falhando (sequer compilando) devido a modificações na base de código de produção que não tem nenhuma relação com a regra coberta pelo teste quebrado. Isso acaba deixando a manutenção dos testes extremamente chata e trabalhosa.

Neste artigo, trago algumas dicas úteis para que possamos construir e manter uma suíte de testes de forma mais “saudável”. Embora o foco esteja em testes de unidade, a ideia central pode ser usada em testes integrados também.

Vamos lá! Continue lendo »

Tell, don’t ask

“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 »

[Conceitos] Command-Query Separation (CQS)

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!

Se não está quebrado, não conserte. Certeza?

Fala, galera!

Li há alguns dias o capítulo 5 do livro do Uncle Bob Agile Principles, Patterns and Practices in C# e resolvi, neste pequeno post, compartilhar com vocês 2 parágrafos do início do capítulo. São coisas nas quais eu acredito demais. Aliás, muitas vezes que leio algo do Uncle Bob, acabo pensando “meu herói!!!!” 🙂

Abaixo, segue a tradução, com pequenas adaptações:

“Cada módulo de um software tem 3 funções:

1) A função que ele desempenha durante a execução. Esta função é a razão de existência do módulo.

2) Proporcionar mudança. Quase todos os módulos de um software mudarão em algum momento de seu tempo de vida e é responsabilidade dos desenvolvedores garantir que tais mudanças sejam as mais simples possíveis de se fazer. Um módulo difícil de mudar está quebrado e precisa de conserto, mesmo que esteja funcionando.

Continue lendo »