domingo, 15 de junho de 2008

Identificadores e Palavras Reservadas - Java

Identificadores e Palavras Reservadas

Identificadores é o que usamos para nomear variáveis, instâncias de classe (que também são variáveis), constantes, métodos e propriedades. Em outras palavras, identificador é tudo que não seja um literal, nem símbolos ou números, nem palavras reservadas. Existem regras que determinam como devem ser declarados os identificadores permitidos em Java (igualmente como em qualquer outra linguagem de programação. Pelo menos, até os dias de hoje). Além dessas regras de sintaxe, a Sun define uma convenção para nomeação de métodos, variáveis e classes. Semelhantemente as demais linguagens de programação, em Java existe um conjunto de palavras reservadas para a linguagem. Isso implica que não é possível usá-las para nomearmos identificadores. Mais tarde falarei detalhadamente sobre a convenção para criação de identificadores para métodos, propriedades e classes em Java.

Obs: Ok, anteriormente escrevi sobre a mesma coisa com uma outra abordagem acho que se vc ainda tem alguma dúvida sobre esse tema pode encontrar ....

Cabe destacar que a adoção de uma padronização quanto a codificação é comum em muitas linguagens de programação, falaremos sobre isso mais tarde.

Regras para nomeação de Identificadores



A sintaxe da linguagem Java define as seguintes regras para se declarar identificadores:

Os identificadores devem começar com uma letra, ou cifrão ($), ou Underscore ( _ ). Não é permitido caracteres numéricos para iniciar um identificador.

Palavras reservadas não podem ser usadas como identificadores.

A linguagem Java é case sensitive (sensível a caixa) para identificadores. Exemplo: Cliente e cliente são, para o compilador, identificadores diferentes.

Não há limite para o número de caracteres usados para compor um identificador.

Exemplo de identificadores grafados de forma correta:

int _a;
String $Coisas;
double _$;
double um_Exemplo_de_nome_bastanteZn_Prolixo_para_um_identificadorZn;

Em seguida veja exemplos de identificadores declarados de forma não aceitável para o compilador.

int :b;
int -di
int e#;
int .f;
int 79;


Exemplo de um programa em Java para testarmos as regras sobre identificadores citadas:
Primeiro veremos um programa “dummy” cujo os identificadores criaremos de forma convencional.


import javax.swing.JOptionPane;
/**
*
* @author Gerson
*/
public class Main {

/**
* @param args the command line arguments
*/
public static void main(String[] args) {
String znSaida = "";
int EstacaoZn = 2;

for (int i = 1; i <= 10; i++){ if (i == 5) continue; znSaida += i + " "; } znSaida += "\n bleng Zn! Skip --> 5";
JOptionPane.showMessageDialog(null, znSaida);
System.exit(0);
}

}



Segundo veremos o mesmo programa “dummy”, contudo alteraremos os nomes dos identificadores para as situações específicas definidas pelo Java 5.

Criando um novo projeto no NetBeans





Definindo o diretório onde o projeto seja salvo





/*
* To change this template, choose Tools | Templates
* and open the template in the editor.
*/

package exemploidentificadoreszn2;

import javax.swing.JOptionPane;
/**
*
* @author GMottaZn
*/
public class Main {

/**
* @param args the command line arguments
*/
public static void main(String[] args) {
String _znSaida = "";
int $EstacaoZn = 2;
String um_Exemplo_de_nome_bastanteZn_Prolixo_para_um_identificadorZn;
for (int i = 1; i <= 10; i++){ if (i == 5) { $EstacaoZn = (4 + $EstacaoZn); continue; } else{ $EstacaoZn = (10 + $EstacaoZn); um_Exemplo_de_nome_bastanteZn_Prolixo_para_um_identificadorZn = "Estaçao ZN = "; } ; _znSaida += i + " " + um_Exemplo_de_nome_bastanteZn_Prolixo_para_um_identificadorZn; } _znSaida += "\n bleng Zn! Skip --> 5 - $EstacaoZn = " + $EstacaoZn;
JOptionPane.showMessageDialog(null, _znSaida);
System.exit(0);
}

}




Artigo completo (View Full Post)

Abordagem OO Java - Introdução

Recorrentemente temos abordado POO aqui no blog. Nosso foco maior tem sido Delphi e C#, contudo sempre que podemos procuramos ampliar nossos exemplos experimentando outras linguagens. Vamos falar um pouco desse contexto no mundo Java.

Breve revisão sobre Java

Um programa em Java é sempre uma coleção de objetos comunicando-se com outros. Comunicação essa que acontece mediante a chamada de métodos (evocação de métodos) uns dos outros. Nunca esquecendo, de ter sempre em mente que cada objeto é de um determinado tipo, definido por uma classe ou interface. Não desprezado o fato dessa coleção de objetos, a qual mencionei anteriormente, ser quase sempre composta por objetos de uma variedade diferente de tipos. Vejamos as seguintes definições sobre OO (Estou usando como referência para este artigo o livro da Kathy Sierra, certificação Sun (Java 5), primeiro capítulo):


Classe:
Um modelo que descreve os tipos, de estado e de comportamento, que os objetos do seu tipo podem ter.

Permita-me um comentário: Particularmente, eu acho essa definição satisfatória para quem já conhece bem orientação a objetos. Contudo, para quem esta aprendendo programação ou vem de uma cultura de programação estruturada, duvido que o parágrafo anterior agregue algum valor, no que tange o processo cognitivo de quem o está lendo. Em outros artigos eu e o Felipe usamos outras abordagens para este conceito. Sugiro que você complemente o entendimento lendo as demais definições, principalmente se você ainda esta dando os primeiros passos em OO.

Objeto:
No momento da execução do programa, quando a JVM (Java Virtual Machine) encontra a palavra reservada “new” ela cria uma instância da classe, referenciada no trecho de código corrente. A isso chamamos de criar um objeto (em outras palavras: instanciar um objeto). Esse objeto recém criado terá seu próprio estado, bem como um comportamento. O qual será expressado como reflexo de todas as funcionalidades, definidas por métodos na classe, que são dinamicamente acessíveis ao objeto.
Quem são essas classes acessíveis ao objeto??? Isso se refere a herança. Um objeto cujo tipo é, por exemplo, uma classe “X” terá acesso ao comportamento de todos os ancestrais dela. Ou seja, ele poderá se comportar como a classe “X”, a classe “XPai”, bem como a classe “XAvo” e assim sucessivamente até o ancestral mais alto (o qual chamamos de super classe). Falaremos mais sobre herança adiante.

Estado:
Variáveis de instância – Cada objeto (que por sua vez é uma instância de uma classe) terá seu conjunto único de variáveis de instância conforme definido na classe (definidos pelos atributos da classe). Em contra partida, coletivamente os valores atribuídos as variáveis de instância de um objeto, expressam o estado do mesmo. Ou, os valores persistidos pelas propriedades do objeto, expressam o estado do mesmo.
Ou seja, o conjunto de atributos do objeto definirá, a partir dos valores definidos neles, o estado desse objeto. Por exemplo: Suponha que temos um objeto “Lâmpada”, esse objeto é possuidor de um conjunto de atributos: Potência, Voltagem, Cor e etc. Devemos considerar que este objeto, além desses, possua outro atributo que definirá se “Lâmpada” esta acesa ou não. Esse atributo pode se chamar “Ativa”, ele indica se ela está acessa (ou seja, ativa) ou não. Logo, quando todos esses atributos possuírem valor, exemplo: Lâmpada.Cor = Amarela, Lâmpada.Voltagem = 110, Lâmpada.Potência = 100W e Lâmpada.Activa = Verdadeiro. Posso agora então conhecer o estado desse objeto.

Comportamento:
Quando codificamos uma classe, e implementamos os métodos dela, estamos definido a lógica da classe. “É nos métodos que a lógica da classe é armazenada” (Achei essa definição muito apropriada). Através dos métodos, o verdadeiro trabalho da classe é realizado. Ou seja, a razão de ser da classe, onde seu principal objetivo é definido. Neles e por meio deles, algoritmos são executados e os dados são manipulados.

Herança:
Característica da orientação a objetos que permite o reaproveitamento do código de uma classe por outra. Em Java é possível definir uma superclasse “genérica” (mais abstrata) e em seguida estendê-la criando outras classes mais específicas. A superclasse não tem conhecimento algum sobre as classes que descendem dela. Em contra partida, essas classes herdeiras precisam declarar explicitamente a relação de herança. Como efeito disso, uma subclasse que herda de uma superclasse “recebe automaticamente”, digamos assim, as variáveis de instância acessíveis, bem como os métodos definidos na superclasse. Além disso possui autonomia para redefinir os métodos herdados da superclasse, a fim de expressar um comportamento mais específico (este fenômeno chamamos de sobrescrita de método. Ou seja uma subclasse pode sobrescrever os métodos herdados).

Identificando Classes (Análise)
Em concordância com o que mencionei anteriormente, é extremamente importante ser obstinado em alcançar um grau de coesão alto na classe que você está definindo. Isso implica diretamente que toda classe deve ter muito bem definido o conjunto de responsabilidades pertinentes ao conceito do mundo real o qual ela representará para um sistema. Por exemplo, imagine um programa cujo objetivo principal é simular uma orquestra: Certamente encontraremos a representação de instrumentos musicais por algumas classes, bem como músicos, partituras e composição musical por outras tantas. Concluir isso é bastante elementar. Contudo, um erro fatal (e na minha opinião muito freqüente) seria definir, em virtude de um equívoco de análise, o comportamento (ou parte dele) de uma classe em outra, ou vice-versa. Por exemplo: A classe instrumentista possuir um método que retorne o compasso corrente. Creeeeeddddooooo!??!?!?!? Visto que, compasso é um atributo da classe partitura. Um programa em Java é constituído tanto por classes construídas pelo programador, quanto por e outras que não (por exemplo, classes Java API). Em Java as classes são organizadas em pacotes, os quais devemos referenciar mediante a palavra reservada “import” a fim de usarmos suas classes em nossos programas. Dessa forma a linguagem fornece uma forma consistente do desenvolvedor nomear, bem como obter acesso, as classes que necessitar. No exame de certificação Java a avaliação aborda muitos dos conceitos relacionados aos pacotes e acesso a classes. Posteriormente detalharemos mais esses temas.

Interfaces:
É uma espécie de superclasse cem por cento abstrata que define os métodos que uma subclasse deve suportar, mas não define como esse método deve se comportar (ou seja, não define come deve ser implementado). Exemplificando, uma interface "Instrumento Musical" pode declarar que todas as as classes de implementação de "Instrumento Musical" (estendidas dela) possuirão um método "reproduzirSom()". Contudo, a interface "Instrumento Musical" não fornece nenhuma lógica para para este método. Isso implica que a classe que implementar "Instrumento Musical" terá a responsabilidade de definir o comportamento dos métodos definidos na interface. Determinando então, desta forma, como cada instrumento irá se comportar particularmente.
Venho sentindo a necessidade de escrever sobre interface não é de hoje, entretanto ainda não consegui preparar um material que me agrade. Esse assunto esta na fila e considero extremamente pertinente.

Artigo completo (View Full Post)

sábado, 14 de junho de 2008

Donwload Day 2008 - Firefox 3

No dia 17 de Junho de 2008 estaremos presente, com certeza. Inclusive, Eu já confirmei minha participação.
Trata-se da data oficial do lançamento do Firefox 3. Nós do Estação ZN estamos participando, torcendo, apoiando e convocando todos os leitores à esta iniciativa.
Acredito que essa ação vai além de uma brincadeira cujo objetivo é um Record irrelevante. Sua participação consciente é muito importante. O Mozilla Foundation faz o apelo com essas palavras:
Tudo o que você precisa fazer é baixar o Firefox 3 durante o Download Day - é fácil assim. Não estamos pedindo que você engula uma espada ou equilibre 30 colheres no rosto ao mesmo tempo - apesar de que isso seria incrível. inscrevendo-se hoje para baixar o Firefox 3”.

Use a cabeça, pense. Pois quando a cabeça não pensa o corpo e o bolso é que pagam.
Saiba mais em:

Download Day - Portuguese


Artigo completo (View Full Post)

quarta-feira, 11 de junho de 2008

NetBeans 6.1

A Sun Microsystems não brinca em serviço, o projeto NetBeans (fundado a aproximadamente oito anos), do qual é a principal patrocinadora, é um bom exemplo disso. Neste projeto, ao logo de sua trajetória, mostra de forma incontestável o investimento dessa organização em ser uma referencia no mercado também na área de desenvolvimento.

O ambiente de desenvolvimento NetBeans (IDE) - é completamente escrito em Java, está na versão 6.1 e pode suportar qualquer linguagem de programação. Com um grande diferencial: A IDE NetBeans é um produto livre, sem restrições comerciais de como ela pode ser usada. Ela é open source, livre para uso comercial e não comercial. O código fonte está disponível para ser usado através da licença Common Development and Distribution License (CDDL). O Netbeans 6.1 está disponível para download em: Download NetBeans 6.1
Siga as instruções para instalação: Instalação


Para quem desejar se aprofundar nesse caminho, aconselho conhecer o netbeans.org. É o endereço da comunidade NetBeans, cujo o objetivo é construir uma IDE de nível mundial, e disseminar esse produto. O foco dessa tribo é Java, mas, não se engane, lá você pode aprender muito sobre C++, Ruby, XML, tecnologias para web (Javascript, Ájax e etc..). Através do netbeans.org é possível, de forma democrática, ter acesso a pessoas e recursos da comunidade NetBeans.
Tanto para baixar as últimas versões da IDE, ver a documentação on-line, aumentar seu conhecimento sobre Java, quanto acompanhar notícias, ou participar de listas de discussão. Em outras palavras expandir seu universo, tudo isso é possível na comunidade. A própria comunidade incentiva a participação ativa dos seus, digamos, usuários/leitores. Lembrando que, uma boa parte dos tutorias possui tradução para o Português. Isso certamente é relevante para quem encontra dificuldade com o Inglês. Faça download da IDE e experimente o quick start em Português.



Existe uma variedade considerável de listas de discussão, a comunicação entre os usuários do NetBeans é fator positivo a mais a favor da ferramenta. Click e confira, a página de listas é: http://www.netbeans.org/community/lists/index.html

Notícias semanais e mensais: Inscreva-se Inscreva-se na lista nbannounce.
Converse com outros usuários NetBeans, troque dicas aumentando de forma efetiva seu conhecimento (saiba mais).

Artigo completo (View Full Post)

terça-feira, 27 de maio de 2008

Linq to Objects - Parte 2

Click here to read this post in English

Olá a todos. Vou dar continuidade ao post anterior sobre Linq to Objects e mostrar algumas outras funcionalidades desta tecnologia que eu tenho achado tão legal. Espero que vocês também achem legal à medidade que eu vou mostrando as coisas que eu tenho visto e estudado. Vamos nessa!

Nos posts anteriores eu mostrei a sintaxe de query do Linq, mas há uma outra forma de fazer consultas com Linq. Todas as instruções (até mais algumas) que usamos nas queries Linq podem ser representada por chamadas de métodos das classes de coleções. Vamos fazer uma consulta na nossa lista do outro post:

var Meses = new List<string> {
"Janeiro",
"Fevereiro",
"Março",
"Abril",
"Maio",
"Junho",
"Julho",
"Agosto",
"Setembro",
"Outubro",
"Novembro",
"Dezembro"
};

var MesesComJ =
Meses
.Where(mes => mes.StartsWith("J"))
.OrderByDescending(mes => mes)
.Select(mes => mes);

foreach (var m in MesesComJ) {
Console.WriteLine(m);
}


Esta forma, na minha opinião, não é tão legal quanto a outra, mas com certeza também é legal e também mostra de forma clara o que o código quer recuperar.

Para listas simples o select é opcional, mas apenas na forma de métodos - na sintaxe de query é obrigatório.

Hey, que operador maluco é aquele ali? Qual, o =>? Ele é o operador usado para Lambda Expressions. Ah, legal... Mas o que são Lambda Expressions?

Alguns métodos de objetos aceitam como argumento uma definição de função em vez de um valor fixo. Vamos rever o caso do .Where:

.Where(mes => mes.StartsWith("J"))


Vale lembrar que este é um único parâmetro que está sendo passsado para o método. Quando a função fizer a iteração completa na lista ela vai usar este parâmetro para decidir se o item que está na dada posição vai retornar na lista resultante ou não.

Para isso nós definimos a função ali, na hora, criando a condição de retorno de registro. Mas para criar o filtro nós precisamos do contexto. É aí que entra o operador "goes to" (vai para). Ele serve para indicar qual é o contexto da função que estamos criando. Esta condição vai ser testada para cada item da lista (mes.StartsWith("J")), onde mes é o elemento corrente da lista, ou seja: para cada linha da iteração mes será o item corrente. Este tipo de expressão é comum em linguagens funcionais. Vale lembrar que o nome da variável antes do operador é definida por nós, e o código do outro lado deve usar o mesmo nome.

Há muitas expressões de query em Linq; e mesmo que eu soubesse todas este post seria quilométrico! Vamos aqui ver mais dois interessantes: Skip e Take.

Em C# não há representação para Skip e Take na sintaxe de query, somente em métodos. O Skip serve para "pular" resultados e o Take para "pegar" um certo número de linhas:

var Meses456 =
Meses
.Skip(3)
.Take(3);


O resultado será:

Abril
Maio
Junho


A chamada e a ordem dos métodos já nos diz o que a consulta vai retornar: "Pule 3 itens e pegue 3".

Dá para combinar a linguagem de query e as expressões também:

var MesesCom5Letras = (
from mes in Meses
where mes.Length == 5
orderby mes descending
select mes)
.Skip(1)
.Take(2);


O resultado será:

Junho
Julho


À medida em que eu vou aprendendo coisas novas eu posto aqui para o pessoal do Estação. Até treinem e postem aqui suas experiências também. Um grande abraço e até a próxima.

Artigo completo (View Full Post)

Linq to Objects - Part 2

Clique aqui para ler este post em Português

Hello everyone. I'll continue to talk about Linq to Objects in this post and show some other features present in this technology I have found very nice. I really hope you all like it as I continue to show the things I have seen and learned. Let's get to it.

In the previous posts I've shown the Linq query syntax, but there's another way to query data with Linq. All of the statements (in fact even more than that) we see in the query syntax can be represented by Collections' special method calls. They're called query expressions. Let's take a look at the previous example, this time using the method calls:

var Meses = new List<string> {
"Janeiro",
"Fevereiro",
"Março",
"Abril",
"Maio",
"Junho",
"Julho",
"Agosto",
"Setembro",
"Outubro",
"Novembro",
"Dezembro"
};

var MesesComJ =
Meses
.Where(mes => mes.StartsWith("J"))
.OrderByDescending(mes => mes)
.Select(mes => mes);

foreach (var m in MesesComJ) {
Console.WriteLine(m);
}


This form, imho, is not as cool as the another one, but it's also nice and shows us clearly what the code is going to get too.

Working with simple lists the select call is optional, but only in query expressions - in query syntax is still mandatory.

Hey, what is that weird operator over there? What, the =>? This is the operator we use for Lambda Expressions. Oh, ok... But, what are Lambda Expressions?

Some object methods take a function definition as an argument instead of a fixed value. Let's see the Where line again:

.Where(mes => mes.StartsWith("J"))


Let's note that there's only one argument passed to the method. When the Where method do the full iteration over the list it'll use the funcion defined in this argument to decide if the item at the given position will return in the result list or not.

For that we define the function right there, on the fly, creating the return condition for the items. But to create a dynamic filter we need a context. And here comes the "goes to" operator. It's used to point out what is the context in the function we're defining. This condition is going to be tested for each item in the main list, where mes is the current item. Use of this kind of expression is common in functional languages. The variable name before the operator is defined by us, and the code on the right side have to use the same name.

There are many query expressions in Linq; and even if I knew all of them this post would take ages! Let's see here other two interesting ones: Skip and Take.

There's no representation for Skip and Take in the query syntax in C#, only via method calls. Well, the Skip "Skips" a given number of items and the Take "Takes" a given number of items of the result.

var Meses456 =
Meses
.Skip(3)
.Take(3);


This'll produce the result:

Abril
Maio
Junho


The order of the methods call already gives us a tip of what's goind to happen: "Skip 3 and take the 3 next".

We can combine the query syntax with query expressions too:

var MesesCom5Letras = (
from mes in Meses
where mes.Length == 5
orderby mes descending
select mes)
.Skip(1)
.Take(2);


Resulting:

Junho
Julho


As I'm lerning new stuff I post here for you guys. Until there practice a bit and post your experiences here too. Thank you for the support and take care.

Artigo completo (View Full Post)

segunda-feira, 26 de maio de 2008

Linq to Objects - Consultando dados em memória

Click here to see the English version of this post

Olá a todos. O assunto deste post continua sobre a tecnologia Linq, mas desta vez vamos ver um segmento específico: Linq to Objects.

Antes de começar vou recomendar a todos o livro sobre Linq que estou lendo agora: Linq in Action, dos autores Fabrice Marguerie, Steve Eichert, Jim Wooley, publicado por Manning. Eu não encontrei literatura em português para Linq, então dois grandes amigos meus (Claudão e Fernandão) me deram de presente de aniversário. Um dos melhores presentes que eu já recebi até hoje hehe. Valeu galera! Além de cobir Linq ainda mostra muito de C# e boas práticas.

Voltando à tecnologia. Esta tecnologia nos permite realizar consultas em coleções de dados em memória. instâncias do tipo array, List e outras que implementam a interface IEnumerable podem ser usados com Linq. Basta adicionar o namespace System.Linq no nosso arquivo de código que já podemos utilizar o Linq.

Linq to Objects é particularmente útil quando precisamos obter dados de uma coleção em memória e adicionar funcionalidades de filtro e/ou ordenação. Estas tarefas feitas sem o Linq requerem uma boa quantidade de código para ser implementadas usando loops e variáveis temporárias. Outra vantagem de usar o modo de queries do Linq to Objects é a maior legibilidade do código e facilidade de manutenção e depuração, visto que a instrução mostra claramente o que vamos obter como resultado. Vamos a um exemplo prático:

string[] Meses = {"Janeiro",
"Fevereiro",
"Março",
"Abril",
"Maio",
"Junho",
"Julho",
"Agosto",
"Setembro",
"Outubro",
"Novembro",
"Dezembro"};

var MesesComJ =
from mes in Meses
where mes.StartsWith("J")
orderby mes descending
select mes;

foreach (var m in MesesComJ) {
Console.WriteLine(m);
}


O resultado será:

Junho
Julho
Janeiro


Como seria para gerar este mesmo resultado sem Linq? Se quiser se divertir um pouco e praticar algoritmos, fique à vontade :)

Agora imagine se, em vez de um array de strings pudéssemos fazer uma query com uma lista de objetos? E é possível:

class Program {

class Pessoa {
public string Nome { get; set; }
public string Sobrenome { get; set; }
}

static void Main(string[] args) {

var Felipe = new Pessoa { Nome = "Felipe", Sobrenome = "Guerço" };
var Gerson = new Pessoa { Nome = "Gerson", Sobrenome = "Motta" };

var Pessoas = new List<Pessoa> {Gerson, Felipe};

var qry =
from pessoa in Pessoas
orderby pessoa.Nome
select pessoa;

foreach (var p in qry) {
Console.WriteLine("{0} {1}", p.Nome, p.Sobrenome);
}
}
}


Aqui só vou desviar um pouco do Linq para mostrar novos recursos da linguagem C# para quem não conhece. Primeiro, auto propriedades:

public string Nome { get; set; }


Esta implementação cria a propriedade e, por trás das cortinas, cria os campos encapsulados para armazenar os valores das propriedades públicas. Muito útil para aquelas propriedades que são lidas e escritas diretamente nos campos, sem lógica de validação, ao mesmo tempo que deixa preparado para o futuro, sendo necessário somente terminar a implementação porque a propriedade já está definida.

Depois, tipos inferidos pelo compilador:

var Felipe = new Pessoa { Nome = "Felipe", Sobrenome = "Guerço" };


Nas versões anteriores nós tínhamos que definir o tipo da variável antes de inicializá-la. Com esta nova técnica o compilador infere o tipo da variável de acordo com o valor que é passado na inicialização. Não se engane: a definição de tipo ainda é forte, apenas nós não precisamos repetir o que a inicialização já diz. O compilador mesmo assim infere o tipo de dados correto na variável. Para variáveis declaradas sem inicialização nós ainda devemos definir o tipo previamente.

Por fim, um construtor especial:

var Felipe = new Pessoa { Nome = "Felipe", Sobrenome = "Guerço" };


Este construtor nos permite criar uma nova instância de uma classe já definindo suas propriedades.

Agora voltando ao Linq. Aqui selecionamos todas as pessoas da lista ordenando pela propriedade Nome. Se quiséssemos, poderíamos adicionar um filtro por nome adicionando uma cláusula where na consulta:

where pessoa.Nome.Contains("xxx")


Legal né. Mas ainda tem mais! Podemos juntar na mesma query coleções de dados relacionados:


class Program {

class Pessoa {
public string Nome { get; set; }
public string Sobrenome { get; set; }
}

class Pet {
public string Nome { get; set; }
public Pessoa Dono { get; set; }
}

static void Main(string[] args) {

var Felipe = new Pessoa { Nome = "Felipe", Sobrenome = "Guerço" };
var Gerson = new Pessoa { Nome = "Gerson", Sobrenome = "Motta" };

var Meg = new Pet { Nome = "Meg", Dono = Felipe };
var Rex = new Pet { Nome = "Rex", Dono = Gerson };
var Max = new Pet { Nome = "Max", Dono = Gerson };
var Nina = new Pet { Nome = "Nina", Dono = Felipe };

var Pets = new List<Pet> { Meg, Rex, Max, Nina };

var qry =
from pet in Pets
orderby pet.Dono.Nome
select new {
NomeDono = pet.Dono.Nome + ' ' + pet.Dono.Sobrenome,
NomePet = pet.Nome
};

foreach (var p in qry) {
Console.WriteLine("{0} {1}", p.NomeDono, p.NomePet);
}

}
}


Agora veremos mais um recurso interessante: Anonymous types.

select new {
NomeDono = pet.Dono.Nome + ' ' + pet.Dono.Sobrenome,
NomePet = pet.Nome
};


Aqui definimos um novo tipo (anônimo porque é definido ao mesmo tempo em que inicializamos as propriedades). Agora temos um objeto com as propriedades NomeDono e NomePet. O compilador define automaticamente os tipos de dados das propriedades de acordo com sua inicialização.

Agora vamos fazer uma pequena totalização. Vamos mostrar o dono e quantos pets ele possui:

var qry2 =
from pet in Pets
group pet by pet.Dono.Nome + ' ' + pet.Dono.Sobrenome into donos
select new {
Nome = donos.Key,
Pets = donos.Count()
};

foreach (var p in qry2) {
Console.WriteLine("Pets de {0}: {1}", p.Nome, p.Pets);
}


Agora nós criamos um grupo na query agrupando pets com a chave sendo o nome do dono. Neste grupo temos a propriedade Key, que representa o que estamos agrupando. Aí projetamos no resultado a chave do grupo e o contador de registros de cada grupo.

Antes de acabar vou fazer somente uma ressalva: Podemos usar estes resultados como fontes de dados para qualquer controle data-aware de WinForms ou WebForms (GridView, por exemplo).

Bem pessoal, acabou ficando com um tamanho legal, mas espero que tenha mostrado a quem ainda não conhecia como o Linq to Objects pode ser uma boa opção para trabalhar com dados em memória em nossas soluções. Grande abraço e até a próxima!

Artigo completo (View Full Post)

Linq to Objects - Querying in-memory collections

Clique aqui para ver a versão em português deste post

Hello everyone. This post's issue continues about the Linq technology, but this we'll see a specific segment: Linq to Objects.

Before we begin, I want to recommend the book about Linq that I'm reading now: Linq in Action, from the authors Fabrice Marguerie, Steve Eichert, Jim Wooley, published by Manning. It's indeed a great book and will cover not only Linq, but C# features and best practices as well.

Let's get back to Linq to Objects. This technology allows us to query in-memory data collections. Instances of type array, List and others that implement the IEnumerable interface can be used with Linq to Objects. You only need to add a using entry to the namespace System.Linq.

Linq to Objects is particularly useful when we need to query, filter and/or order an in-memory data collection. These tasks when done without Linq (traditional ways) require quite a lot of code that uses loops and temporary variables. Another advantage on using Linq is that the code is easier to read, maintain and debug, as the code clearly shows what we'll get as result. Look at the example:

string[] Months = {"January",
"February",
"March",
"April",
"May",
"June",
"July",
"August",
"September",
"October",
"November",
"December"};

var MonthsWithJ =
from mon in Months
where mon.StartsWith("J")
orderby mon descending
select mon;

foreach (var m in MonthsWithJ) {
Console.WriteLine(m);
}


The result will be:

June
July
January


How would we produce the same result without Linq? If you want to have some fun and practice some algorithms, suit yourself :)

Now, let's say if, instead of an array of strings we could query an Object list? Yeah, it's possible:

class Program {

class Person {
public string FirstName { get; set; }
public string LastName { get; set; }
}

static void Main(string[] args) {

var Felipe = new Person { FirstName = "Felipe", LastName = "Guerço" };
var Gerson = new Person { FirstName = "Gerson", LastName = "Motta" };

var People = new List<Person> {Gerson, Felipe};

var qry =
from person in People
orderby person.FirstName
select person;

foreach (var p in qry) {
Console.WriteLine("{0} {1}", p.FirstName, p.LastName);
}
}
}


Now we'll take a little break on Linq to show some of the new C# features for those that doesn't know them yet. First, auto properties:

public string FirstName { get; set; }


This implementation creates the property and, behind the scenes create the encapsulated field to store the property value. Very usefil for those properties that are read and written directly in the fields and don't need any specific validation logic behind them. But, at same time, provide structure to future changes, as the get and set are already there.

Next, type inference

var Felipe = new Person { FirstName = "Felipe", LastName = "Guerço" };


In early versions we had to define the variable type before initialize it. With this new feature the compiler infers the type in the first value assignment. Make no mistake: the type definition is still strong (not variant); we just don't need to explicitly inform the type because the compiler knows it from the assignment. To define a variable without initialize we do need to inform the type.

At last, a special constructor:

var Felipe = new Person { FirstName = "Felipe", LastName = "Guerço" };


This constructor allows us to create an instance of a class setting the properties rigth away.

Now Let's get back to Linq. Here we'll query all people on the list sorting by FirstName. If we wanted, we could add a search criteria by Name adding a where clause:

where person.FirstName.Contains("xxx")


Cool, isn't it? But there's more! We can query related data in more complex collections:


class Program {

class Person {
public string FirstName { get; set; }
public string LastName { get; set; }
}

class Pet {
public string Name { get; set; }
public Person Owner { get; set; }
}

static void Main(string[] args) {

var Felipe = new Person { FirstName = "Felipe", LastName = "Guerço" };
var Gerson = new Person { FirstName = "Gerson", LastName = "Motta" };

var Meg = new Pet { Name = "Meg", Owner = Felipe };
var Rex = new Pet { Name = "Rex", Owner = Gerson };
var Max = new Pet { Name = "Max", Owner = Gerson };
var Nina = new Pet { Name = "Nina", Owner = Felipe };

var Pets = new List<Pet> { Meg, Rex, Max, Nina };

var qry =
from pet in Pets
orderby pet.Owner.FirstName
select new {
OwnerName = pet.Owner.FirstName + ' ' + pet.Owner.LastName,
PetName = pet.Name
};

foreach (var p in qry) {
Console.WriteLine("{0} {1}", p.OwnerName, p.PetName);
}

}
}


Now let's see another new interesting feature: Anonymous types.

select new {
OwnerName = pet.Owner.FirstName + ' ' + pet.Owner.LastName,
PetName = pet.Name
};


Here we define a new type (anonymous because it's defined at same time that we set the properties). Now we have an object with properties named OwnerName and PetName. The compiler automatically infers the properties' types according with their initialization.

Now we're goind to do an aggregation. We'll show the owner and how many pets they have:

var qry2 =
from pet in Pets
group pet by pet.Owner.FirstName + ' ' + pet.Owner.LastName into ownerPets
select new {
Name = ownerPets.Key,
Pets = ownerPets.Count()
};

foreach (var p in qry2) {
Console.WriteLine("{0}'s Pets: {1}", p.Name, p.Pets);
}


Now we created a group in the query counting pets with a key being the Owner's name. In this group we have a property named Key, which represents the information we're grouping. Then we project the group key and the group count in the resultset.

Before we finish, let me point out something: We can use these query results as data sources for data-aware controls, such as GridViews on WinForms or WebForms.

Well, it ended up more lengthy than I expected, but i think that it could show some of the power and usefulness of Linq to Objects technique. Thank you all for the support and see you at the next post. Take care!

Artigo completo (View Full Post)

Acesso a dados com Linq

Click here to see the english version of this post

Olá a todos. Peço desculpas pelo tempo em que estive sem postar aqui no blog. Antes de chegar no assunto gostaria muito de mandar um obrigado especial a todos os visitantes do Estação ZN, que está crescendo em acessos cada vez mais. Nós nos sentimos muito orgulhosos e felizes de ver que este conteúdo que nós postamos aqui e que são freqüentemente retirados de conversas e problemas do dia-a-dia está chegando a todos que acessam nosso blog. Se o que é postado aqui consegue ajudar, fazer pensar, ou até mesmo distrair alguém nosso trabalho já valeu a pena.

Para compensar vou postar sobre um assunto que nos (eu e o Gerson) deixou boquiabertos: Linq - Uma nova tecnologia de acesso a dados presente no Visual Studio 2008 e na .Net 3.5.

Linq é sigla para Language-integrated query. Significa que é uma tecnologia (ou melhor, um conjunto delas) que adiciona recursos de consulta semelhantes às queries da linguagem SQL no nível da linguagem (compilador).

O que isso quer dizer? Que esta tecnologia nos permite (entre outras coisas) consultar dados em memória, arquivos XML e até de bancos de dados relacionais de forma declarativa (funcional), ao invés da maneira imperativa tradicional que usamos.

Linq veio também para diminuir uma coisa chamada "impedance mismatch", que representa a diferença entre o modelo de classes/objetos do software e os modelos de entidades/relacionamentos do banco e dos arquivos XML. Explicando um pouco melhor: Vamos partir do seguinte princício: Dados Relacionais <> XML <> Objetos. No software nós utilizamos o modelo POO, com herança, polimorfismo e por aí vai. Os dados que nossos aplicativos geralmente acessam estão representados em forma de tabelas em bancos de dados relacionais ou arquivos XML. Entre estes três mundos nós não temos praticamente nenhuma compatibilidade; até os tipos de dados são diferentes.
Hoje em dia, para trabalhar com estes dados em nossos aplicativos nós precisamos usar as APIs que as linguagens nos fornecem. Mas nós sempre precisamos escrever mais código que deveríamos, e o código que escrevemos para acessar estes dados não representa claramente o resultado que queremos. Isso se deve à maneira imperativa que as linguagens requerem para acesso aos dados.

Ah, Felipe..., ..., ... Ok. Vamos a um exemplo:

Queremos fazer um select no banco de dados. Há algumas pequenas diferenças entre linguagens, mas a idéia é a mesma:


  • 1. Abre conexão com o banco de dados

  • 2. Cria um objeto para realizar a consulta.

  • 3. Passa a consulta SQL para ele.

  • 4. Executa a consulta e retorna para um objeto que armazena o resutset.

  • 5. Libera os recursos e usa o resultset.



Este modelo nos traz a necessidade de implementar, de forma imperativa, o que o sistema deve fazer em cada momento. Também precisamos escrever código para conexão e execução da query, que não faz parte diretamente da lógica e, por fim, temos que enviar a query para o banco como uma string, onde só saberemos se tem algum erro de sintaxe em tempo de execução. Então, quando o banco retornar os resultados teremos que "traduzir" este resultset em objetos para se encaixar ao nosso modelo de classes do programa. Em resumo: muito código e de difícil leitura, manutenção e depuração.

Mas como o Linq é diferente? Primeiro vamos ver os diversos tipos de formas do Linq. Primeiro temos o Linq to Objects, que nos permite selecionar e ordenar e filtrar coleções em memória. Vamos dar um exemplo:

string[] Meses = {
"Janeiro",
"Fevereiro",
"Março",
"Abril",
"Maio",
"Junho",
"Julho",
"Agosto",
"Setembro",
"Outubro",
"Novembro",
"Dezembro"};

var MesesComA =
from mes in Meses
where mes.StartsWith("A")
orderby mes descending
select mes;

foreach (var m in MesesComA) {
Console.WriteLine(m);
}


Dê uma olhada na parte onde consultamos o array de string Meses. Neste trecho fazemos uma consulta no array Meses onde trazemos qualquer elemento que comece com a letra A e ordenamos o resultado em ordem decrescente. Desta forma acessamos os dados de forma declarativa, assim como nas linguagens funcionais. Imagine como escreveríamos este código na forma imperativa padrão...

Em Linq to Objects, podemos fazer este tipo de consulta em qualquer classe que implemente a interface IEnumerable (o array implementa essa classe, embora não pareça).

Este modelo de queries pode ser aplicado também em dados do banco de dados e arquivos XML. Mas como? Primeiro vamos falar do banco de dados - não vamos nos aprofundar muito porque o objetivo deste post é mostrar o que é Linq e do que ele capaz.

Nós fazemos consultas em bancos de dados da mesma forma declarativa que consultamos coleções de objetos. Mas Felipe, se eu tiver que trazer uma tabela inteira do banco e ter que transformá-la em array para depois fazer a consulta pode jogar esta tecnologia fora! Com certeza a Microsoft não faria isso com uma tecnologia que visa facilitar a vida dos desenvolvedores. O Linq to SQL funciona com uma outra tecnologia da linguagem: Mapeamento de entidades.

Em Linq to SQL nós temos nossos objetos no programa e os decoramos com atributos especiais de mapemento (Em outros posts eu falo e mostro mais sobre isso). De forma mais simples, nós marcamos nossas classes como "Classes de entidade" do banco de dados e informamos as tabelas e campos que nossos objetos/propriedades representam; então, quando consultamos estes objetos, o Linq monta a query para o banco de dados e "traduz" os objetos e propriedades em tabelas e campos. O Linq trata intrinsecamente todos os processos que são necesários mas não fazem parte da lógia do programa, como conexão com o banco, obtenção de registros e tradução de resultsets em objetos.

Linq to SQL vai além disso, provendo também API de atualização de dados, transação e controle de concorrência.

Linq to XML provê uma API simples e única para consultar e também criar arquivos XML; uma API muito mais simples que as atuais que conhecemos (DOM, XSL, XPath, XQuery). A sintaxe de consulta é muito semelhante à Linq to Objects, e esta padronização é muito boa nós desenvolvedores nos acostumarmos rapidamente.

Como o objetivo deste post é falar sobre uma nova tecnologia e ter uma visão geral, vou deixar os "sabores" específicos do Linq para outros posts. Até lá procurem mais e divirtam-se.

Um grande abraço a todos e até a póxima.

Artigo completo (View Full Post)

Data access with Linq

Clique aqui para ver este post em português

Hello everyone. This is the first post in Estação ZN in English. We decided to give an "English version" to our posts due to the increasing non-Brazilian public of our blog, which we would like say thank you very much. From now on I'll try to make an English translation of every post i make. I ain't a native English speaker, so please bear with me a little bit. :)

Let's get started. In this post I'm bringing an issue that left me and Gerson speechless: A new data access technology present in Visual Studio 2008 and .NET 3.5.

Linq stands for Language-integrated Query. It's a technology (a few of them, in fact) that adds query capabilities at language (compiler) level.

What does it mean? It means that Linq allows us (amongst others things) to query in-memory data, XML files and even relational database tables in a declarative manner (like funcional languages) instead of the traditional, imperative way we're used to.

Linq also came to propose a solution for the "impedance mismatch", that is the difference between the program's object model (OOP) and the relational databases/XML files data model. Going a bit deeper: Let's begin with the principle: Relational data <> XML files <> Objects hierarchy/relationships. At the software we have the OOP model, with inheritance, polimorphism and so on. The data our software usually accesses are represented in relational database tables and XML files. In these worlds we have no compatibility whatsoever; even the data types are different.
In order to work with data nowadays we need to use APIs that the languages provide us. But we always have to write more code than we should, and the code that we write to access the data doesn't clearly represent what we want to do. That is because of the imperative way that the languages require to access and manipulate data on external sources.

Eh..., ..., ... Ok. Here's an example:

We want to query data from a database. There are minor differences between the languages but it all comes down to one path in most cases:


  • 1. Open connection with the database

  • 2. Instantiate an object to execute the query

  • 3. Pass the query as string

  • 4. Send the query to the database and get the resultset

  • 5. Release the resources and uses the resultset



This model comes with the necessity of implement, in a imperative way, what the program has to do at each moment. We also have to write code to explicitly connect to the database and run the query, which isn't part of our program logic, and at last, but not least, we have to code the query as string, not using the compiler's type checking at design time - if our query has any errors, we'll discover it only at run time. Then, when the application retrieve the data from the database we have to manually "translate" the database's resultset into objects. It takes too many "unnecessary" code (I would say code that doesn't belong there) and produces code that is difficult to read, mantain and debug.

But how's Linq different? First, let's see the several "flavors" of Linq. We'll see the Linq to Objects first, which allows us to query, filter and sort in-memory collections. Let's go on a example:

string[] Months = {
"January",
"February",
"March",
"April",
"May",
"June",
"July",
"August",
"September",
"October",
"November",
"December"};

var MonthsWithA =
from mon in Months
where mon.StartsWith("A")
orderby mon descending
select mon;

foreach (var m in MonthsWithA) {
Console.WriteLine(m);
}


Take a look at the part where we query the string array Months. In this fragment we search the Months array for any month that starts with the letter A and sort the results descending. This way we access the data in a declarative way, like we would do with funcional languages. Imagine how would be the code to achieve the same results in the traditional, imperative way...

In Linq to Objects we can query any object that implements the IEnumerable interface (the array implenents this interface even though it doens't look like).

This querying model can be applied in relational data and XML files too. But how? Let's see the relational database first - We won't dive too deep into it for now because this post's objective is to show what is Linq and what it is capable of.

With Linq to SQL we can query the database in the same declarative way we do on object collections. But Felipe, if I have to retrieve the entire table from the database and convert it into an array before I can use the Linq, then I surely don't want it! For sure Microsoft wouldn't do it with a technology that is intended to make the developers' life easier. Linq to SQL works with another new language enhancement: Entity Mapping.

In Linq to SQL we have the classes in our program decorated with the special Mapping attributes (I'll talk about and show it in another posts). In other words, we'll "mark" our classes as "Entity classes" and inform which tables and fields are related to which classes and properties; and then, when we query these objects, Linq "mounts" the query and retrieve the results into the objects - all thanks to the mapping attributes.

Linq to SQL can do way more than this. It also provides APIs for data updates, transactions and concurrency control. We'll see more of that later.

Linq to XML provides a simple and unified API to query and also create/edit XML files; an API that is way simpler than those we know nowadays (DOM, XSL, XPath, XQuery). The query syntax is very alike to the Linq to Objects, and this is very nice to us developers to get used to quickly.

As the goal of this post being talk about a relatively new technology and have a peek into all this, I'll let the specific "flavors" of Linq to other posts. See you all and have fun.

Thank you for spending time with us, and please excuse me about any English errors, as i'm no native English speaker, and feel free to send any suggestions and even corrections (please correct me!). Bye...

Artigo completo (View Full Post)

 
BlogBlogs.Com.Br