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...

Olá, galera! Hoje tive o prazer de participar de um hangout com meus antigos colegas de trabalho Leandro Magnani, Luiz Pais, Alexandre Costa (Magoo), Gabriel Vieira e Vinícius Tosta sobre coisas que todos os desenvolvedores devem saber. Confira no vídeo abaixo. []'s

Muitos profissionais de TI possuem ou já possuíram empresas abertas para prestação de serviços, pois muitos lugares trabalham com essa forma de contratação terceirizada. Mas depois se a pessoa muda para um trabalho onde seja contratado como CLT, manter uma empresa aberta pode gerar gastos mensais com sua manutenção que são desnecessários. Para uma pessoa encerrar uma empresa são necessários vários passos burocráticos. Envolvem a interação com vários órgãos como Previdência Social, Junta Comercial, Receita Federal, prefeituras, entre outros (este link possui um resumo caso você tenha curiosidade http://www.sebrae.com.br/sites/PortalSebrae/artigos/Como-fechar-uma-empresa:-passo-a-passo-para-encerrar-as-atividades ). Mesmo sendo possível uma pessoa enfrentar toda essa burocracia e fazer todo o processo de encerramento sozinha, é muito mais prático contratar alguém especializado para fazer esse trabalho. Geralmente o próprio contador que manteve a empresa ativa durante o tem...

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...

Muito do material que vemos pela Internet a respeito de Inversão de Controle e Injeção de Dependência está relacionado ao ASP.NET MVC. Hoje o meu objetivo aqui é mostrar como fazer uso de um contêiner de IoC com o "patinho feio" do ASP.NET, o Webforms. Mas antes, vamos contextualizar o que é Inversão de Controle e Injeção de Dependências. Inversão de Controle é um conceito de programação onde é tirada a responsabilidade de uma classe em criar as suas dependências. Vejamos o código abaixo. Nele, a página ASP.NET (que é uma classe) instancia uma classe chamada SaudacaoPTBr e chama seu método Saudar para retornar uma informação qualquer. Por isso, esta página depende de SaudacaoPTBr. Perceba que para utilizar essa dependência, a página ASP.NET teve que, no seu próprio código, criar um objeto do tipo SaudacaoPTBr. public partial class _Default : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { var saudacao = new SaudacaoPTBr(); ...

Olá, pessoal. Hoje vou falar sobre cache, mas quero fazer algo diferente dos muitos materiais que se encontra na Internet. Não numa visão de codificação prática, mas sim conceitualmente, explicando o resultado que tive ao implementá-lo em uma aplicação ASP.NET que possuía sérios problemas de desempenho. Primeiramente, qual é o conceito de cache? A idéia do cache é ter uma cópia de um conjunto de dados para acesso rápido. Dessa forma não oneramos o repositório original, cujo acesso é mais lento que o cache, ao fazer buscas. A seguinte imagem mostra como um algoritmo de cache comumente é feito. Alguém faz uma requisição ao cache, buscando determinada informação. Caso essa informação não exista no cache, ele vai ao repositório original para carregá-la e o insere no cache. A partir disso, qualquer busca por esta informação no cache vai trazer o dado armazenado, ao invés de efetuar a pesquisa no repositório “lento”. A vantagem do cache está em melhorar o desempenho de pesquisas. O pri...

Um dos objetivos mais desejados pelos gerentes no desafio de desenvolver sistemas é a reutilização de componentes com a finalidade de economizar trabalho e tempo (ou seja, dinheiro). Com essa idéia na cabeça e uma boa dose de boa vontade, os desenvolvedores e arquitetos procuram criar ferramentas e componentes que possam ser compartilhados dentro da corporação (frameworks técnicos). Em muitos casos, apesar do esforço, esse objetivo não é alcançado, e acabamos citando o ditado “de boas intenções o inferno está cheio”… Não estou dizendo que a reutilização é um conceito ruim, ao contrário, é claro para a indústria de software prova a necessidade e importancia dela a cada dia. No entanto, gostaria de compartilhar as minhas experiências em relação à esse assunto para ajudar a evitar as armadilhas que aparecem quando decidimos criar um framework corporativo. Trabalhei bastante tempo criando e mantendo esse tipo de software, e acho que tenho algumas boas histórias… Separei três principais...

Pessoal, saiu outro artigo meu na .NET Magazine 76 , ainda a respeito de design patterns: nesta edição, eu abordo os padrões Composite e Chain of Responsibility. []’s

O MVP é um padrão para a construção de aplicações que interagem com o usuários (User Interface) que tem dois objetivos principais: Separar as responsabilidades na camada de apresentação, ou seja, o que é da tela e o que é da lógica de negócio do aplicativo. Facilitar os testes,  permitindo que os mesmos sejam automatizados. O pattern MVP pode ser separado em duas categorias: Passive View e Supervising Controller . A diferença entre os dois é o grau de testabilidade que cada um provê. Hoje iremos ver alguns detalhes da primeira categoria, com foco na questão de separação de responsabilidades. A idéia aqui é separarmos o que o que é da apresentação e o que é da lógica de acesso aos objetos do domínio de negócios. O diagrama acima mostra como temos essa separação entre as classes que compõe a estrutura básica do MVP Passive View. Do lado da camada de apresentação, temos a classe View, que no final das contas será uma tela WPF ou uma página ASP.NET. Do...

Recentemente recebi de um colega de trabalho um link de um artigo escrito por Rockford Lhotka, criador do framework de desenvolvimento de aplicações CSLA .NET . Neste arquivo, ele comenta sobre o mau uso dos design patterns nas aplicações. Ele condena o uso de padrões sem critério algum, ou seja, quando se faz o uso deles apenas por se “achar bonito”, sem se preocupar em realmente identificar um problema a ser resolvido. Isso acontece muito, principalmente quando se lança uma tecnologia nova ou um pattern se torna popular. Temos a tendência de nos “regogizarmos mentalmente” quando fazemos algo complexo. Em resumo, o artigo cita que se deve: Utilizar patterns quando se tem um problema a resolver e o padrão se aplica. Utilizar o padrão quando suas qualidades superarem suas desvantagens (sim, nenhum pattern é perfeito, todos têm seu lado ruim). Combinar padrões simples para enfrentar problemas complexos. Quando usado um padrão, ter certe...

Design patterns não têm segredos: tratam-se de soluções bem experimentadas e documentadas para problemas comuns. São as boas soluções para problemas que sempre enfrentamos. E esse conceito não está relacionado apenas à TI (aliás, nem começou na TI, começou na engenharia). Se observarmos, até na natureza existem tais conceitos de patterns. Tomemos como exemplo o vôo das aves. Existe um problema que é o desgaste que uma ave tem ao voar longas distâncias, geralmente em rotas migratórias. Para resolver esse problema, os pássaros voam em grupos, em uma formação “V”: dessa forma, as aves que estão atrás da primeira se aproveitam do vácuo gerado pelo vôo da líder, diminuindo o atrito com o ar e conseqüentemente diminuindo a energia gasta por elas. Quando o primeiro pássaro se cansa, ele vai para o final do grupo, e é substituído. Com isso, o grupo consegue uma autonomia de vôo em média 70% melhor do que se estivessem sozinhos. Este padrão de vôo é utilizado por aeronaves militares e também ...

Pessoal, escrevi um artigo sobre design patterns na edição 72 da .NET Magazine . Ele foca em cima dos padrões Strategy e Flyweight . A idéia foi dar um conceito geral sobre esses padrões, e depois criar uma aplicação onde se faça uso deles ao mesmo tempo. Isso surgiu da questão onde eu achava na Internet apenas exemplos isolados de uso de patterns, quase impossível encontrar coisas onde o uso era combinado. Espero que gostem! []’s