Fala pessoal!

Idéia
Neste artigo continuaremos a série sobre Algoritmos! No primeiro artigo resolvemos 3 problemas bem simples, utilizando a idéia de pseudocódigo, onde podemos visualizar melhor os passos para a resolução de um problema e não precisamos conhecer nenhuma linguagem de programação nesta etapa.
Neste segundo artigo vamos resolver o primeiro problema apresentado anteriormente, já utilizando Java e C.

Pra você que está iniciando os estudos e não conhece muito bem a sintaxe das linguagens não se preocupe pois a idéia desta série é mostrar os passos para a resolução de um problema e vamos usar essas linguagens só para os problemas não ficarem tão vagos!
Vamos lá!

Quebrando em pequenos pedaços
Conforme havia dito no artigo anterior, podemos dividir um problema em passos para chegar na sua resolução final. A idéia de divisão de um problema em problemas menores já é antiga e facilita muito a nossa vida, pois podemos pensar na resolução de "mini-problemas", deixando de lado a visão macro do problema. Após a resolução dos pequenos problemas, o problema maior é resolvido através da união destes.

Primeira resolução
Para o nosso primeiro código, vamos atacar o problema 1 do artigo anterior. Vamos lembrá-lo:
"Problema: Fazer a divisão de um número por outro. Se o resultado for positivo, imprimir o número encontrado pela divisão, caso seja negativo, imprimir zero. Caso o divisor seja zero, imprimir o valor -1."

No artigo anterior também vimos a resolução deste problema através de um fluxograma e também criamos um pseudocódigo com a intenção de fazer qualquer pessoa entender o objetivo que gostaríamos de atingir, que é a resolução do problema acima.

Ambiente
Com o problema em mãos, vamos fazer o passo a passo da resolução já utilizando as duas linguagens citadas, pra que possamos visualizar o fluxo em um nível mais baixo.
Para o Java, utilizarei o Eclipse e para o C utilizarei o DevC++. Particularmente não gosto do DevC++ e uso o GCC do Ubuntu, mas o DevC++ é bem utilizado pelos que estão começando. O Eclipse talvez não seja o mais usado pelos iniciantes (o comum é usarem editores simples) , mas ele é muito conhecido. Fique à vontade para desenvolver no NetBeans, JCreator, JBuilder, etc.

Relembrando
Esqueça a sintaxe do código abaixo caso você não a entenda agora. O ponto forte aqui pra você que está começando é entender o conceito, a lógica, a idéia. Pense na situação simples: Pra você pedir um cafezinho, você segue alguns passos, como encontrar um local, chamar o garçom, escolher o café, ver o preço e pedir. E você vai fazer exatamente a mesma coisa se estiver no Brasil, Japão ou na África e só vai mudar o idioma, a "sintaxe"!
Portanto, entender os passos neste momento é muito mais útil e fundamental que entender a sintaxe, a linguagem.

Primeiro código em Java
Vamos criar o nosso primeiro código em Java. Para isso, vamos criar uma classe com o nome de "DivisaoDeNumeros". Esta é a classe que irá conter a nossa lógica para a resolução do problema. Com a classe criada, vamos criar o método "main" para podermos executar a aplicação, ou seja, imprimir os dados.

//Classe que trata das divisões de números
public class DivisaoDeNumeros {
    public static void main(String[] args) {

    }
}

Agora com a classe e o método principal criados, vamos fazer o passo a passo do artigo anterior, porém escrevendo em código! Pra não ficar uma leitura muita cansativa e demorada fazendo cada passo, escrevi o código inteiro e comentei cada passo no próprio código.

public class DivisaoDeNumeros {

	public static void main(String[] args) {
		//Criamos um objeto Scanner para capturar o que foi digitado
		Scanner input = new Scanner(System.in);
		//Imprime mensagem para a inserção do primeiro valor
		System.out.println("Insira o valor do dividendo: ");
		//Guarda o valor digitado pelo usuário na variável dividendo
		int dividendo = input.nextInt();
		//Imprime mensagem para a inserção do segundo valor
		System.out.println("Insira o valor do divisor: ");
		//Guarda o valor digitado pelo usuário na variável divisor
		int divisor = input.nextInt();

		//Verifica se o valor do divisor é igual a zero
		if (divisor == 0) {
			//Imprime o valor -1 caso o divisor seja zero
			System.out.println("-1");
		}
		//Verifica se o valor do cálculo da divisão é negativo
		else if ((dividendo / divisor < 0)) {
			//Imprime o valor 0 caso o resultdo da divisão seja negativo
			System.out.println("Valor encontrado: 0");
		}
		else {
			//Como o divisor não é zero e o cálculo não é negativo, imprime o resultado da divisão
			System.out.println("Valor calculado: " + dividendo / divisor);
		}
	}
}

Você pode perceber que a execução está bem simples! Pelos comentários, podemos ver que passamos pelo "passo a passo" do artigo anterior, mas desta vez não escrevemos um pseudocódigo e sim um código em Java que podemos executar. Se você não está acostumado com a sintaxe, perceba que não foi difícil de entender o conceito, a idéia por de trás do código.

Esta é uma possível solução do problema, e não única. Podemos ter outros passos pra resolução! Mas será que se só trocarmos as condições (if's / else if's) teremos o mesmo resultado? Que tal tentar dar uma olhada no código abaixo e ver qual o problema?

import java.util.Scanner;

public class DivisaoDeNumeros {

	public static void main(String[] args) {
		//Criamos um objeto Scanner para capturar o que foi digitado
		Scanner input = new Scanner(System.in);
		//Imprime mensagem para a inserção do primeiro valor
		System.out.println("Insira o valor do dividendo: ");
		//Guarda o valor digitado pelo usuário na variável dividendo
		int dividendo = input.nextInt();
		//Imprime mensagem para a inserção do segundo valor
		System.out.println("Insira o valor do divisor: ");

Fala pessoal!!!

Com este breve artigo(breve mesmo!) vou falar sobre o conceito de Inversão de Controle, que muitos confundem com Injeção de Dependência. É justo, já que no primeiro momento os dois conceitos são bem parecidos.

O que é a Inversão de Controle (IoC)?
Basicamente, a Inversão de Controle é uma forma diferente que temos para manipular o controle sobre um objeto. É um padrão. Gosto de pensar na Inversão de Controle como sendo a mudança de conhecimento que uma classe tem em relação à outra.

Gosto de ver um trecho teórico com um trecho de código, então vamos ver desta forma!

Vamos imaginar uma classe bem simples, onde precisamos gravar um Log em um arquivo após Vender um Produto.
Então podemos ter a seguinte classe bem simples:

public class VendaDeProduto {
	public void vendeProduto(Produto produto) {
	    //Todo o código para a venda do produto...
	    Log log = new Log("Arquivo.txt");
	    log.grava(produto);
	}
}

Mas qual o problema?
Razoável o exemplo. Uma classe facilmente encontrada em qualquer código. Eu sou ruim para perceber problemas em uma classe só de vê-la, então vou imaginar uma situação real: Percebemos que a classe Log precisa do arquivo onde será gravado o Log correto? Agora vamos imaginar que o nome do arquivo será mudado para "ArquivoLog.txt"! Muito fácil, basta mudar o nome correto? Vamos então abrir a classe VendaDeProduto e mudar!

Putz! Aqui que está o problema! O que a classe de Venda tem a ver com isso? Na verdade, nada! Ou pelo menos não deveria ter. Para uma modificação na classe Log fomos obrigados a modificar algo dentro da classe de Venda e isso não é legal. Neste momento foi fácil modificar, mas e se tivéssemos 30 classes utilizando a classe Log? Quais as chances de esquecermos uma?

No pequeno exemplo acima vimos um detalhe importante: A classe VendaDeProduto sabe demais sobre a classe Log. A classe VendaDeProduto sabe criar a classe Log. Pior, a classe de vendas sabe que a classe Log precisa do nome de um arquivo! E isso não é justo com a classe VendaDeProduto.
A responsabilidade dela é somente de fechar uma venda. Portanto podemos ver um alto acoplamento de classes neste minúsculo código.

Um problema mais a fundo
Pra você que desenvolve com TDD, como faríamos por exemplo para fazer um teste com a classe VendaDeProduto quando precisarmos "mocká-la"? Simplesmente não conseguimos, justamente por ela criar o objeto Log! E não vale você que conhece o PowerMock inventar algo! :)

Resolvendo o problema
É aqui que entra a Inversão de Controle. Vamos literalmente inverter este controle na classe VendaDeProduto. Em vez de deixarmos a responsabilidade da criação da classe Log para a classeVendaDeProduto, vamos dar a ela esta dependência. Vamos injetar esta dependência nela. E olha o que apareceu para nós: Injeção de Dependência.

Daí muitos confundirem e acharem que os dois são a mesma coisa. Como você pode ver, vamos resolver o problema desta classe Invertendo o Controle, utilizando a Injeção de Dependência. Simples assim!

Vamos resumir: Injeção de Dependência é apenas uma forma para resolvermos a Inversão de Controle.

Temos algumas formas interessantes de Injeção de Dependência e vou falar da mais comum(em um próximo post falarei de outras!): O Constructor Injection, ou seja, injetamos uma dependência de uma classe através do construtor desta classe.

Vamos novamente exemplificar este trecho de teoria com um pouco de código. Para sermos mais coerente, vamos melhorar um pouco mais o nosso código anterior, utilizando a Injeção de Dependência!

public class VendaDeProduto {
        private Log log;

        public void VendaDeProduto(Log logVenda) {
             this.log = logVenda;
        }

	public void vendeProduto(Produto produto) {
	     //Todo o código para a venda do produto...
	     log.grava(produto);
	}
}

Ol

Fala Desenvolvedores!!!

Neste artigo teremos a continuação da parte III da série sobre TDD. A idéia deste artigo é continuar comentando um pouco mais sobre os Testes de Unidade e também falarmos sobre os Testes de Unidade em relação ao comportamento dos nossos objetos. Também falaremos sobre o conceito de Mock de Objetos, que é extremamente importante no TDD.

Já vou adiantar que você ficará chateado com o que faremos para "Mockar" os nossos objetos, mas prometo que em seguida ficaremos muito felizes com uma solução bem mais bacana para isso. Calma! o conceito de "Mockar" objetos aparecerá logo logo!

Para iniciar este artigo, vamos fugir um pouco do conceito citado acima e fazer a funcionalidade de divisão de dois números para verificarmos a possibilidade de fazer Testes esperando que alguma Exceção ocorra. Isso mesmo! Por algum motivo você deseja lançar uma Exceção caso algo de errado aconteça e podemos fazer isso com o JUnit, apresentado no artigo anterior.

Teste da divisão
A funcionalidade é simples: Fazer a divisão de dois números. Lembrando: É um caso simples e isolado onde a intenção é você imaginar um caso real da sua aplicação.
Então vamos para o Teste!

Mas aqui começaríamos com aquele conceito de BabySteps, onde faríamos passos curtos para chegarmos à solução, correto? Correto, porém os BabySteps não são uma regra xiita que devemos seguir à risca. Segundo o próprio Kent Beck em seu livro sobre TDD, os BabySteps são para quando realmente não temos confiança suficiente em escrever determinado código. Como ele cita também, não devemos desenvolver com BabySteps a todo momento e sim devemos ficar felizes por podermos fazê-lo quando desejarmos.

Agora que lembramos disso, vamos correr um pouquinho mais no código e escrever um pouco mais rápido que no artigo anterior, porém sinta-se à vontade para colocar a sua velocidade:

Adicionando o método de Teste à nossa classe de CalculadoraTeste:

public class CalculadoraTeste {
	@Test
	public void deveriaDividirDoisValoresPassados() throws Exception {
		int valorA = 6;
		int valorB = 2;
		Calculadora calculadora = new Calculadora();
		int divisao = calculadora.divide(valorA, valorB);

		assertEquals(3, divisao);
	}
}

E na nossa classe Calculadora, vamos escrever o nosso método de produção:

public class  Calculadora {

	public int divide(int valorA, int valorB) {
		return valorA / valorB;
	}
}

Legal! Agora podemos rodar o nosso Teste e vê-lo passando. Uma observação simples: Não comentei nos artigos anteriores mas só para ter certeza que é de conhecimento de todos, vou comentar: Rodamos os nossos Testes clicando com o botão direito na classe de Teste, selecionando Run As e em seguida selecionando o JUnit Test.

Agora temos um Teste verde na nossa frente!

Maravilha! Finalizamos? Não.

E quando esperamos por uma exceção?
Vamos atormentar os professores de matemática e fazer a seguinte alteração na nossa classe de Teste:

public class  CalculadoraTeste {
	@Test
	public void deveriaDividirDoisValoresPassados() throws Exception {
	        int valorA = 6;
  	        int valorB = 0;  //divisão por zero!
	        Calculadora calculadora = new Calculadora();
	        int divisao = calculadora.divide(valorA, valorB);

	        assertEquals(?, divisao);
	}
}

O que fizemos: atribuímos o valor zero à variável valorB. E o que esperamos no nosso assertEquals? Não tenho noção! Podemos esperar tudo, menos um valor! Sendo assim, na sua aplicação, você poderia mostrar uma mensagem para o usuário solicitando gentilmente que ele insira um valor coerente. E como podemos fazer um Teste esperando uma exceção? Vamos lá!

Teste esperando por uma exceção
Podemos usar um parâmetro na própria anotação do JUnit (@Test) para indicar qual a exceção que estamos esperando receber. Assim teríamos o seguinte código para o nosso Teste:

public class  CalculadoraTeste {

	@Test
	public void deveriaDividirDoisValoresPassados() throws Exception {
	        int valorA = 6;
		int valorB = 3;
		Calculadora calculadora = new Calculadora();
		int divisao = calculadora.divide(valorA, valorB);

		assertEquals(2, divisao);
	}

	@Test
	public void deveriaLancarUmaExcecaoIndicandoFalhaAoDividirUmNumeroPorZero()
             throws Exception {
		int valorA = 6;
		int valorB = 0;
		Calculadora calculadora = new Calculadora();
		int divisao = calculadora.divide(valorA, valorB);

		assertEquals(0, divisao);
	}
}

Mas infelizmente ao rodar, temos uma barra vermelha:

Agora sim podemos fazer o nosso Teste passar adicionando o parâmetro à anotação do JUnit (@Test):

public class CalculadoraTeste {

	@Test(expected = ArithmeticException.class)
	public void deveriaLancarUmaExcecaoIndicandoFalhaAoDividirUmNumeroPorZero()
            throws Exception {
		int valorA = 6;
		int valorB = 0;
		Calculadora calculadora = new Calculadora();
		calculadora.divide(valorA, valorB);
	}
}

E agora sim temos a barra verde para o nosso Teste:

Este foi um caso simples para mostrar como é possível trabalhar com Testes que devem verificar exceções. Podemos estender este conceito para outros momentos, como fazer um Teste que não deveria esperar uma exceção que já esta poderia ser tratada pela nossa classe Calculadora, pois fazer da forma acima não é tão interessante.

Agora vamos melhorar os nossos testes!

Indo mais além
Até agora fizemos testes bem simples e a idéia é imaginarmos outras funcionalidades em nossas aplicações reais de forma a desenvolvê-las desta forma.Claro que uma classe do tipo Calculadora não é o melhor dos exemplos, mas optei pela simplicidade até agora.

De qualquer forma, tenho certeza que sua aplicação poderá ter muitas funcionalidades que, se bem isoladas, serão também passíveis de testes semelhantes.

Agora podemos avançar um pouco mais! Começamos o artigo com uma nova palavra: "Mock".
Definição simples: Um Mock é basicamente um objeto falso, que é capaz de simular as dependências de um objeto e é capaz de simular determinadas ações desse objeto.
Por que é usado? Para testar o comportamento de outros objetos desejados.

Por que gostaríamos de testar o compo

Fala Desenvolvedores!!!

Servlets! Nesta série de artigos pretendo falar um pouco sobre os Servlets de uma forma simples e prática e falando também na teoria, que dará uma base melhor quando estiverem nascendo os nossos primeiros códigos com Servlets.

A idéia é também evoluir este assunto para outro assunto bem interessante, o JSP! Vocês verão mais pra frente que, a grosso modo, o JSP é convertido em Servlets.

Tá Alexandre, mas já que os artigos falarão sobre Servlets, nada mais justo que começar o primeiro falando sobre o motivo do nascimento dos Servlets.
Então vamos lá!

O problema!
Como toda boa idéia, os Servlets surgiram justamente a partir de um problema: A necessidade de exibição de páginas geradas dinamicamente na Web.
E por que? Por que no começo tínhamos páginas estáticas, ou seja, páginas muito simples em HTML que não eram capazes de retornar respostas de acordo com as requisições dos usuários.

Resumindo a história: No começo tínhamos diversos servidores que continham diversas páginas HTML estáticas que simplesmente acessávamos seu conteúdo e agora temos páginas que nos respondem dependendo da nossa pergunta, ou seja, capazes de enviar diferentes tipos de respostas dinamicamente.

Solução interessante: CGI
CGI. O Common Gateway Interface (CGI) foi criado justamente para contornar este problema. Qual era a idéia do CGI? Receber a requisição do cliente e gerar páginas web dinamicamente, exatamente como queríamos!Uau! Como? Podíamos escrever programas em CGI que poderiam ser executados a partir de parâmetros passados pelo navegador. Sendo um pouco mais ortodoxo, temos scripts CGI que entendem os parâmetros passados pelo navegador e assim podem enviar uma página web para o navegador criada dinamicamente, de acordo com estes parâmetros.

Exemplo simples: Com CGI podemos fazer uma solicitação via web e um programa CGI pode ler dados de um banco de dados a partir da nossa requisição e devolver uma página HTML com estes dados.

Uma curiosidade é que poderíamos escrever os programas usando por exemplo PHP, C, ASP e Perl.

Mas em Java também temos algo semelhante, os Servlets!

Servlets
Basicamente os Servlets funcionam desta mesma forma: Podem gerar páginas dinamicamente, de acordo com as requisições do usuário.

Os Servlets são da plataforma Java e nada mais são que Classes onde podemos criar objetos e trabalhar com eles, gerando páginas HTML dinamicamente.

Assim, basicamente poderíamos ter o seguinte processo:

Fala Desenvolvedores!!!

Neste artigo teremos a continuação da parte II da série sobre TDD. Desta vez codificaremos nosso primeiro pequeno exemplo trivial, um Hello World do TDD! Entre um código e outro, claro que também lembraremos de alguma teoria e alguns pontos interessantes.

Hello World do TDD
Sim. Pra você que está ansioso por algo um pouco mais complexo, realmente neste momento não vamos ter. Assim podemos nivelar o conhecimento com um exemplo trivial, afim de não deixar ninguém perdido.
Vamos lá!

Ambiente
Para o nosso "sistema" vou utilizar Java+Eclipse+JUnit . Imagino que você já conheça um pouco de Java e Eclipse, portanto não mostrarei a instalação deles pois fugiremos do escopo do artigo. Caso tenham algum problema, é só entrar em contato.

Alexandre, posso fazer em C#? A vontade! Pode usar C#+NUnit. Posso usar Delphi? A vontade! Pode usar Delphi+DUnit!
Caso alguém queira, posso escrever utilizando um deles também.

Primeiro exemplo
Este será um exemplo bem trivial. No nosso "sistema" precisaremos criar uma Calculadora que calcula as 4 operações básica: Adição, Subtração, Multiplicação e Divisão. Simples assim!
Vamos lá!

Passos para a criação do projeto:
- Crie um novo projeto no Eclipse com o nome de "ArtigoTDD"
- Crie um pacote com o nome "artigotdd.calculadora.teste"

Com a estrutura básica criada, agora vamos criar a nossa primeira classe. A classe Calculadora Alexandre? Não! A classe CalculadoraTeste? Isso mesmo. Vamos fazer um Teste em algo que ainda não temos implementado.

Assim, criamos a classe CalculadoraTeste no pacote criado:

package artigotdd.calculadora.teste;

public class CalculadoraTeste {

}

Tudo certinho por aqui. Agora devemos pensar sobre o nosso problema. Queremos fazer algumas operações nesta calculadora e para começarmos pensaremos em uma soma. Como podemos testar uma soma?
Simples e trivial: Dados dois valores, o resultado deveria ser a soma deles.

Vamos então escrever exatamente este Teste! Vamos criar um método que indique este teste. Para o JUnit entender que o método é "testável", temos a anotação "@Test" no método (Não esqueça do import do JUnit).

Assim temos:

public class CalculadoraTeste {
	@Test
	public void deveriaSomarDoisValoresPassados() throws Exception {

	}
}

Isso mesmo. O nome do nosso método deve mostrar exatamente o que ele está querendo fazer. É comum encontrar métodos de teste começando com "deveria" e inglês você também vai encontrar o "should".

Agora que temos o método de teste, vamos indicar pra ele o que queremos. Vamos agora inserir duas variáveis e usar o método "assertEquals" do próprio JUnit.

Como o próprio nome diz, o "assertEquals" indica que estamos querendo afirmar algo. (Não esqueça do import: "import static org.junit.Assert.*")

Vamos ao código:

public class CalculadoraTeste {
	@Test
	public void deveriaSomarDoisValoresPassados() throws Exception {
		int valorA = 1;
		int valorB = 2;
		int soma = 0;

		assertEquals(3, soma);
	}
}

Pronto! Queremos o resultado 3 para a soma das variáveis valorA e valorB. Acabamos de escrever o Teste e óbvio que ele não passa. Vamos rodá-lo? Botão direito na classe de teste -> Run As -> JUnit Test.
Barra vermelha, era o que temíamos!

Fala Desenvolvedores!!!

Dando continuidade à parte I da série continuaremos neste artigo com TDD, desta vez destrinchando um pouquinho mais a metodologia para escrevemos o nosso primeiro código.

O primeiro artigo foi bem simples, apenas uma breve introdução para apresentar os conceitos e alguns motivos para o uso da técnica do TDD.
Vamos agora avançar um pouco mais para ter uma visão melhor e um pouco mais profunda.

Sendo chato, parte I
Sei que é chato, mas ainda falarei um pouco de teoria neste início, para que realmente possamos entender (leia-se lembrar!) sobre alguns conceitos e motivos do uso de TDD.
Como havia dito, o TDD se baseia no seguinte ciclo:

Vamos entender um pouco sobre cada etapa:

Novo Teste
Este primeiro passo é o pilar do TDD (não brinca!). Temos uma nova funcionalidade do sistema e fazemos o processo inverso ao tradicional: Testamos e Codificamos e não Codificamos e Testamos.

No primeiro momento isto parece estranho, esquisito ou feio, mas não é. O fato de termos um teste primeiro que o código garante que daremos passos simples para a codificação da funcionalidade, afim de fazer o teste passar, ou seja, seremos "obrigados" a escrever uma implementação simples para que o teste passe.

No começo esta forma não é muito intuitiva e o gráfico de aprendizagem não é lá um dos melhores, mas com o tempo e aperfeiçoamento da técnica, esta será a forma mais intuitiva e segura de desenvolver que você encontrará.

Teste Falhando
Neste momento, acabamos de escrever o teste e não temos a implementação. Óbvio que o teste falhará, pois ele espera uma resposta que ainda não temos implementada em lugar algum.
Com um Teste falhando na nossa frente, temos um único objetivo na vida: Fazê-lo passar! Passamos para a próxima fase:

Nova funcionalidade
Já ouviu falar no KISS? "Keep It Simple, Stupid", ou seja, devemos escrever o nosso código da forma mais simples possível. Código limpo, simples e funcional! Esta é a idéia.

Assim, neste momento vamos esquecer as Boas práticas, a Inversão de Controle, os Patterns, etc e  vamos codificar a nossa nova funcionalidade da forma mais simples possível para fazer o nosso Teste passar.
Neste momento estamos simplesmente escrevendo alguma funcionalidade que faça o teste passar (sem quebrar outros testes) e também teremos segurança na Refatoração deste mesmo código daqui a alguns minutos.

Vale lembrar também daquela sequência ótima de desenvolvimento que devemos ter na cabeça:
Código que funciona -> Código simples e limpo -> Código rápido

Agora com a nova funcionalidade implementada e o teste passando, seguimos para a próxima fase:

Refatoração
Agora sim! Você purista da programação que condenou a minha geração por eu ter falado para abandonarmos as boas práticas de desenvolvimento, agora sim pode ficar tranquilo!

Neste momento é que vamos analisar melhor aquele código que fizemos simplesmente para o no