Fabio Gouw

Uma das regras que ajudam a nortear o design de objetos é o Princípio de Substituição de Liskov. Esse preceito foi definido inicialmente por Barbara Liskov em 1987 mas ganhou maior divulgação ao compor o grupo de regras chamado SOLID exposto por Robert C. Martin no livro  Agile Software Development: Principles, Patterns, and Practices . Este princípio diz que 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 . Um pouco confuso na primeira vez que se lê, mas que na prática atesta que eu posso substituir uma instância de uma classe por outra instância que seja de uma subclasse da primeira, sem que isso altere o comportamento do sistema. Vamos usar um exemplo para poder explicar melhor. Veja a listagem de código abaixo. Ela simula um sistema de cálculo de imposto para venda de veículos. A classe Carro contém um método chamado CalcularValorImposto que recebe o valor do veícu...

O padrão Decorator, do livro Design Patterns: Elements of Reusable Object-Oriented Software , é útil quando precisamos adicionar um comportamento em uma classe já existente. Vamos demonstrar isso através de um exemplo de uma classe de acesso ao banco de dados onde será adicionado o uso de cache. Primeiro temos  nossa classe que acessará o "banco de dados". Na verdade, a nossa base nada mais é que um array em memória. Optei por fazer assim para manter a simplicidade do exemplo e focarmos no que realmente é importante. Além disso, a busca demora propositadamente 3 segundos para simularmos todo o trabalho de se acessar um recurso externo à aplicação como um banco de dados. // RepositorioConfiguracaoImpl.cs using System.Collections.Generic; using System.Threading; namespace ExemploDecorator { public class RepositorioConfiguracaoImpl : IRepositorioConfiguracao { private readonly Dictionary<string, string> _configuracoes = new Dictionary<string, str...

Já vi sistemas desenvolvidos em linguagens orientadas a objetos em que todos os métodos das classes eram estáticos. Uma vez perguntei para uma pessoa o motivo dela estar programando dessa maneira. Ela não soube me responder. Bom, por que não devemos colocar static em todos os métodos? Para mim, a melhor resposta é comparar o uso de métodos static com o uso de baionetas. Antes do uso da pólvora, as guerras eram travadas geralmente em combate corpo-à-corpo, com o uso de objetos cortantes como espadas ou machados. No final do século XVIII, na França, começaram a ser produzidas as primeiras baionetas. Baioneta é uma arma branca de curto alcance que pode ser presa na ponta de um fuzil. Dessa maneira, em situações especiais como combate próximo (trincheiras) ou simplesmente falta de munição, os soldados possam utilizar suas armas de fogo como lanças. Mas é claro que atualmente, na maioria das situações, é preferível utilizar fuzis com o objetivo que eles foram criados: disparar pro...