- Grok podcast é o que tem assuntos mais variados, já "grokamos" sobre Ruby, Python, Arduíno, Node-JS e mais recentemente Erlang, e outros assuntos como Sistemas de controle de versão, carreira, desenvolvimento de games, e muito mais. Visite o site para saber o que significa o termo grok.
segunda-feira, 22 de agosto de 2011
PodCasts
Olá pessoal. Gostaria de compartilhar com vocês os podcasts que acompanho e que ajudam muito a me manter atualizado sobre vários assuntos.
sábado, 13 de agosto de 2011
Google Developer Day Brasil 2011 - Prova de Programação
Olá pessoal. Após ler o post do Erick Sasse entitulado Prova do Google Developer Day em Delphi decidi aceitar o desafio e resolver a prova (também em delphi) mesmo que eu não vá ao Google Developer Day 2011 Brasil.
A prova é bem interessante, é dado um texto em um alfabeto diferente do nosso e algumas regras para extrair do texto as quantidades de preposições e verbos, ordenar o texto e transformar as palavras em números base 20.
A prova é bem interessante, é dado um texto em um alfabeto diferente do nosso e algumas regras para extrair do texto as quantidades de preposições e verbos, ordenar o texto e transformar as palavras em números base 20.
sábado, 6 de agosto de 2011
Strategy - Separando os comportamentos - Parte Final
No último artigo falei sobre o padrão de projeto Strategy e expus um diagrama de como utilizar o strategy para exportação de dados. Hoje vou mostrar como podemos implementar o padrão seguindo a modelagem do diagrama.
Primeiro, vamos a declaração da interface que define a API de exportação e o enumerator com os formatos de saída suportados.
Primeiro, vamos a declaração da interface que define a API de exportação e o enumerator com os formatos de saída suportados.
type TExporterType = (etText, etCSV, etXML); IExporterStrategy = interface ['{AA69E6F1-389F-4DC3-AC14-7FA7A749B183}'] function GetFileName: String; procedure SetFileName(const Value: String); property FileName: String read GetFileName write SetFileName; procedure ExportToFile(const Value: String); end;
Marcadores:
Factory,
Mock,
Padrões de Projeto,
Strategy
quinta-feira, 4 de agosto de 2011
Strategy - Separando os comportamentos - Parte 1
O padrão de projeto Strategy define uma família de algoritmos, encapsula cada um e os torna intercambiáveis, traduzindo, definimos uma interface, criamos várias implementações para essa interface, e podemos mudar o comportamento do objeto trocando a implementação utilizada. Podemos inclusive fazer isso em runtime.
Vamos observar o diagrama abaixo.
Vamos observar o diagrama abaixo.
Marcadores:
Factory,
Padrões de Projeto,
Strategy
quarta-feira, 3 de agosto de 2011
Singleton em Delphi utilzando interfaces
Olá, dando sequencia ao post anterior sobre Singleton, hoje irei mostrar uma implementação alternativa, e ao meu ver, mais elegante.
Nessa abordagem, o estado e/ou comportamento exposto pelo singleton deve ser declarado em uma interface.
Após a interface, vamos criar uma classe que seja responsável por implementá-la. O detalhe importante é que a classe fique abaixo da seção implementation, isso garante que ninguém fora dessa unit terá acesso a classe, tornado impossível criar uma nova instância da mesma.
Nessa abordagem, o estado e/ou comportamento exposto pelo singleton deve ser declarado em uma interface.
type ISingleton = interface ['{F5B00272-536A-4C30-AB19-54496B106C7C}'] procedure FacaAlgo; end;
Após a interface, vamos criar uma classe que seja responsável por implementá-la. O detalhe importante é que a classe fique abaixo da seção implementation, isso garante que ninguém fora dessa unit terá acesso a classe, tornado impossível criar uma nova instância da mesma.
terça-feira, 2 de agosto de 2011
Singleton em Delphi
O Singleton é um padrão de projeto utilizado para garantir que apenas uma única instância de determinada classe esteja disponível em todo o projeto, ou seja, ele garante que o objeto será instanciado apenas uma vez e será acessivel de forma global.
Isso é muito útil, por exemplo, quando lidamos com factory, pois a factory não precisa ser instanciada a todo momento. Outros exemplos são Pool de Conexões, Registry, Logs, ou recursos que sejam caros de instanciar a cada uso.
Isso é muito útil, por exemplo, quando lidamos com factory, pois a factory não precisa ser instanciada a todo momento. Outros exemplos são Pool de Conexões, Registry, Logs, ou recursos que sejam caros de instanciar a cada uso.
segunda-feira, 1 de agosto de 2011
Usando DUnit para implementar testes unitários - Parte 2
No último post fiz uma introdução sobre a criação de testes unitários com o DUnit. Hoje, vou explorar mais alguns recursos desta poderosa ferramenta, continuando com o exemplo da Calculadora, para isso, a calculadora vai ganhar um método para fazer divisão. Lembram do ritual? Red - Green - Refactor! Vejam a classe de teste, garanta que o teste falhe e então faça-o passar.
procedure TTestCalculadora.DivisaoDe6Por2DeveSer3; var vCalculadora: TCalculadora; begin vCalculadora := TCalculadora.Create; try CheckEquals(3, vCalculadora.Soma(6).DividePor(2).GetTotal, 'Divisão inválida'); finally vCalculadora.Free; end; end;Fail!
function TCalculadora.DividePor(const AValor: Double): TCalculadora; begin FValor := FValor / AValor; Result := Self; end;Success!
Usando DUnit para implementar testes unitários
Esse é meu primeiro post, e vou começar abordando um assunto que ao meu ver é pouco difundido na comunidade Delphi, Testes Unitários, e para isso vou demonstrar como utilizar a ferramenta DUnit para construção dos testes.
Cada vez mais é primordial que o desenvolvedor invista parte de seu tempo na construção de testes, se for utilizando TDD, melhor ainda. Uma boa suíte de teste nos dá segurança e confiança no momento de fazer um refactoring ou a correção de um bug. Também melhora significativamente o design do nosso código, pois, para pode testar de forma realmente unitária, nossas classes precisam ter baixo acoplamento, boa coesão, serem realmente testáveis.
Cada vez mais é primordial que o desenvolvedor invista parte de seu tempo na construção de testes, se for utilizando TDD, melhor ainda. Uma boa suíte de teste nos dá segurança e confiança no momento de fazer um refactoring ou a correção de um bug. Também melhora significativamente o design do nosso código, pois, para pode testar de forma realmente unitária, nossas classes precisam ter baixo acoplamento, boa coesão, serem realmente testáveis.
Assinar:
Postagens (Atom)