Criamos finalmente (!) um blog dentro do site da Sedna, então agora passaremos a  postar lá. Os posts antigos também foram migrados e estarão todos acessíveis a partir do novo endereço:

Blog da Sedna

Visitem, atualizem os favoritos!

Carol

Mas, perai…como que é isso?

A String é um objeto imutável. Isso significa que sempre que você alterar o conteúdo de um objeto String, na verdade você não altera esse objeto. Você cria um novo objeto com o valor alterado.

Um exemplo clássico disso é

A saída é teste e não TESTE. Nesse exemplo, são criados dois objetos String diferentes.

E qual o motivo da String ser imutavel?

Para explicar isso, vamos voltar um pouco e analisar como o .NET gerencia sua memória.

Quando instânciamos um objeto como Integer i = new Integer(1), é criado um objeto Integer e a variável i faz referência à esse objeto. Se depois fizermos um Integer x = i, temos duas variáveis de referência x e i referenciando (o que não é o mesmo que apontando, não é um ponteiro!)  o mesmo objeto que contém o valor 1.

Porém, se em seguida eu continuar meu código com Integer y = new Integer(1), é criado um novo objeto que contém o valor 1 na memória e a variável y referencia a ele. Portanto, x e i fazem referencia a um objeto e y a outro objeto que contém o mesmo valor.

Com Strings, funciona de forma um pouco diferente. A plataforma sabe que muitas Strings se repetem durante a execução de uma aplicação e poderiam ser reaproveitadas, por isso, mantém um pool de Strings.  É menos custoso.

Na execução do código:

Primeiro, é criado um objeto String que contém o valor “a” com a variável s1 fazendo referência à ele. Na segunda linha, ao invés de criar um novo objeto contendo o valor “a”, o .NET identifica que já existe uma String como o mesmo valor em memória e apenas cria a variável s2 e a faz referenciar o objeto já existente.

Toda ação que eu fizer sobre s1 ou sobre s2 que deveria alterar o valor do objeto referenciado mantém o objeto original em memória e cria um novo objeto em memória (exemplo do teste e do TESTE, logo acima).

Existem três formas de usar a classe String

1. Através de concatenação
2. String.format()
3. String Builder

A concatenação é o modo convencional, pouco eficiente e mais prático.

Você nunca deve fazer algo assim:

Utilize esse método para concatenações mais simples (concatenar campos nome e sobrenome, por exemplo).

A concatenação simples também pode ser feita através do método estático String.Concat.

Já o String.format é uma forma de substituir marcações {} na String por parâmetros ou para formatar a String de acordo com um padrão FormatProvider informado em alguns de seus overloads existentes.

Novamente, é um método eficiente para pequenas operações, pois percorrer a string em busca de padrões {} para a substituição não é muito eficiente.

O terceiro modo de utilização de Strings é através da classe StringBuilder.

É o modo mais complexo e o mais eficiente de utilização de Strings. Internamente ele gerencia a memória de uma forma mais adequada que a concatenação tradicional, e é específico para a construção de Strings que são muito alteradas durante sua criação, como comandos DML.

PS: Uma curiosidade:  Em C#, ao se comparar duas Strings com ==,  na verdade é chamado o método Equals da classe String.

Estamos implementando o cadastro de usuários no SCM. A idéia era validar se o usuário tinha digitado pelo menos dois dígitos, uma letra maiúscula e uma mínuscula na senha. Além disto, o tamanho da senha deveria ser entre 6 e 20.

Poderíamos utilizar vários if’s, verificando isto. Um if para letras maiúsculas, um para letra minúscula, um para verificar da cada dígito, um para o tamanho da string… Só de pensar nisto já desanima.

Entretanto, com as expressões regulares podemos ter uma solução em duas linhas:

private function verificaRegExp(senha: String): Boolean {
  var re: RegExp = /(?=.*\d.*\d)(?=.*[a-z])(?=.*[
A-Z])[a-zA-Z0-9]{6,20}/;
  return re.test(senha);
}

A idéia não é mostrar neste post como funcionam as expressões regulares. É apenas mostrar que elas existem e que deixam uma solução menos porca poluída.
É claro que nem tudo são vantagens quanto às Expressões Regulares. É muito difícil de manter este código. Portanto, não deixe de comentar bem o código explicando o que o código faz.

Tem uma referência em .net também. Em Object Pascal (Delphi), ainda não encontrei uma legal. Se alguém conhecer, me fala que eu complemento aqui!

Abraços,
Zé Alexandre

Ps.: Mesmo esta solução sendo boa, talvez não será a que iremos utilizar, pois precisamos de uma “escala” da força da senha.

Estava precisando simplesmente iterar o conteúdo de grids para gerar tabelas HTML, mas o problema era que temos grids alimentadas com coleções flat (ArrayCollection), outras com dados hierárquicos (HierarchicalCollection) e outras ainda no meio do caminho, agrupadas (GroupingCollection). O velho getItemAt() não ia funcionar. Já estava pensando horrorizada em vários ifs, métodos recursivos de busca em profundidade e etc, quando decidi ligar o lazy mode e consultar a boa e velha ajuda do Flex, para ver se já não existia algo parecido pronto.

Eis que descubro as incríveis interfaces ICollectionView e IViewCursor! No caso flat funciona normal, linearmente, e no hierárquico ele faz a busca em profundidade. Com 3 linhas você itera magicamente a coleção, pra qualquer dos tipos que eu falei:

if (dataProvider is ICollectionView) {

var cursor:IViewCursor = dataProvider.createCursor();
while (!cursor.afterLast) {

trace(cursor.current);
cursor.moveNext();

}

}

Nessas horas é que eu me lembro que devo ler mais a documentação e conhecer o framework!

PS: Dizem por aí que há dois tipos de interfaces: aquelas de menininha (relacionadas a design e todas essas “perfumarias”) e aquelas de menininhos (classes burocráticas que o pessoal de OO adoooora). Nesse caso o negócio foi tão clean que nem pareceu uma interface de menininho! =P

Carol

Eis que me deparei de novo com dois fatos tristes, e resolvi dessa vez escrevê-los pra nunca mais ter a ilusão de que eu podia estar enganada e despertar aquele fio de esperança de que tudo poderia se resolver tão facilmente:

• Não existe sobrecarga de métodos em Action Script 3! A título de curiosidade, neste link tem a explicação de como “contornar o problema”, mas infelizmente ainda é bem distante daquela coisa mágica e transparente que a gente aprende em OO…É pena!
• AdvancedDataGrid não herda de DataGrid! Ainda não consegui achar uma explicação pra isso, se alguém tiver comente por favor!

Ainda bem que o AS é bem flexível e sempre dá pra fazer de outro jeito!

Carol

Para isto, duas técnicas utilizadas: o número de referências de um objeto e a marcação e varredura.
O primeiro (reference counting) utiliza o número de referências que um objeto tem. Quando o GC precisar, ele irá remover da memória o objeto que não tiver nenhum referência. Entretanto este método tem um problema: quando há referências circulares para um objeto, ele nunca é liberado da memória.
Este problema é resolvido com a segunda técnica (mark and sweep). Desta forma, ele passa por todos os objetos criados a partir da raíz (no nosso caso o Application do Flex). Os objetos que não tiverem nenhum referência não são marcados e portanto não podem ser acessados. Um exemplo pode ser visto na figura abaixo:


Como resultado, os itens não marcados, que na figura estão em branco, podem ser liberados da memória. Entretanto este é um processo mais custoso, pelo fato de passar por quase todos os objetos.

No artigo ainda existe um simulador para esta segunda técnica que fica bem claro como ele libera os objetos. Façam alguns testes para ver como funcionaria.

Abraços,
Zé Alxandre

Isto aconteceu pois acabamos criando um grupo de e-mails para divulgar as coisas novas que aprendíamos e discutir sobre os problemas do dia-a-dia. Resultado: o blog ficou meio de lado…

Mas o pessoal já voltou colocando novos post no blog (valeu, Elias!). Com o tempo iremos atualizar com o conteúdo discutido nos e-mails.

Aproveitei e atualizei os links com alguns sites legais.

Venho também para divulgar o evento que ocorrerá no dia 6 de fevereiro, o Flex For Kids:

Será um evento que várias pessoas que conhecem Flex no Brasil irão dar palestras online. Todo o lucro conseguido será revertido para as crianças do Cotolengo, uma instituição que cuida de pessoas com paralisia cerebral grave.

Nós da Sedna iremos ver as palestra e ajudar as crianças. Ajudem a divulgar… Além de ajudar as as crianças, poderão aprender bastante sobre Flex.

Abraços,
Zé Alexandre

Mas aí vem o primeiro deploy e a descoberta…putz! Tenho que fazer um Export Release Build pra caaaada um dos meus projetos! Que porcaria improdutivo!

Como todos sabem, o nosso amigo Flex pode ser compilado utilizando tasks do ANT (http://ant.apache.org/).

Ai vem o primeiro pensamento: Beleza! Vou fazer um scriptzinho aqui e resolver minha vida! Mas, como nem tudo são barrinhas verdes de sucesso na vida de um programador, você descobre que construir um script é trabalhoso demais e que as coisas não funcionam como deveriam…

Quando seu script não funciona...

É nesse momento de tristeza que você inesperadamente se depara com o Fx2ANT. Um plugin para o eclipse que lê as configurações de seu projeto e gera os arquivos de build automaticamente! Isso mesmo, ele gera os arquivos! E não é só isso! Os swfs compilados ficam otimizados!

O FX2Ant faz parte do Clear ToolKit (http://www.myflex.org/#products/fx2ant, https://sourceforge.net/projects/cleartoolkit), um pacote de plugins com algumas funcionalidades interessantes para o Flex. Mas atenção, ele só funciona quando o Flex Builder está instalado na versão plugin. Não funciona com a instalação Stand Alone do Flex Builder.

Agora o processo todo é simples:

1. Instale o Java (mínimo versão 5)
2. Instale o ANT
3. Instale o Eclipse (recomendo versão 3.5.1)
4. Instale o plugin do ANT para o Eclipse
5. Instale o plugin do Flex Builder 3 (ele é pago)
6. Finalmente instale o ClearToolKit

Agora é só clicar no projeto com o botão direito e Fx2Ant->Generate Build Files

Em instantes você vê os scripts que ficou horas tentando descobrir como montar!

No meu caso, eu apanhei muito tive que alterar algumas configurações para que a build efetivamente funcione, por isso é importante conhecer o fluxo do script e saber como o ANT funciona…

Depois, é só juntar as chamadas aos diversos arquivos *build.xml gerados (um para cada projeto) em um build.xml, para que executando apenas um comando, você consiga compilar todo seu projeto Flex.

public class ClassA {

static ClassA() { Console.Write(“AA “); }
public ClassA() { Console.Write(“A “); }

}

class ClassB : ClassA {
static ClassB() { Console.Write(“BB “); }
public ClassB() { Console.Write(“B “); }
}

class ClassC : ClassB {
static ClassC() { Console.Write(“CC “); }
public ClassC() { Console.Write(“C “); }
}

Você saberia dizer qual seria a saida ao criar uma instância de ClassC?!

Um “new ClassC()” resultaria em “CC BB AA A B C”

Isso acontece porquê os construtores static são chamados no momento em que a classe é carregada pela “máquina virtual” e, em cada construtor não estático, existe uma chamada implícita ao construtor (com os mesmos argumentos) da classe pai.

É como se o código dos construtores fosse  ClassC() : base(), ClassB() : base()…

Então, o comando new ClassC() executa o bloco estático de ClassC e, na primeira linha de seu construtor não estático, carrega o ClassB, que executa o bloco estático e depois chama o construtor de ClassA, que executa seu bloco estático e chama o construtor de Object. Esse construtor, após terminar sua execução, retorna ao construtor de A, que retorna ao construtor de B, que retorna ao construtor de C!!  O código do construtor de C é a última parte a ser executada!

Confuso? Pense da seguinte forma: Os blocos estáticos são executados de filho para pai, os não estáticos de pai para filho!

Porém, se eu fizer

new ClassC();
new ClassB();

A saida será “CC BB AA A B C A B”, pois os as classes já foram carregadas na “máquina virtual”, então seus blocos estáticos já foram executados.

Até a próxima!

TContaCorrente = class
private
  saldo: double;
public
  constructor Create;
  function getSaldoDisponivel: double; virtual;
  function getSaldo: double;
  procedure setSaldo(value: double);
end;

// indica que herda de TContaCorrente
TContaEspecial = class(TContaCorrente)
private
  limite: double;
public
  constructor Create;
  function getSaldoDisponivel: double; override;
  function getLimite: double;
  procedure setLimite(value: double);
end;

function TContaCorrente.getSaldoDisponivel: double;
begin
  result := Self.saldo;
end;

function TContaEspecial.getSaldoDisponivel: double;
begin
  result := Self.getSaldo + Self.getLimite;
end;

Caso a diretiva override não tivesse sido colocada, ambos os métodos existiriam na classe filha, getSaldoDisponivel da classe TContaCorrente e getSaldoDisponivel da classe TContaEspecial, entretanto o da classe filha seria ocultado e não seria acessado por um objeto do tipo TContaEspecial, não tendo o resultado que você esperava. Em resumo, seria gerado código a toa para os dois métodos quando apenas um deles estaria disponível. E o Delphi acabaria dando um warning. Um professor meu falava que para encarar os Warnings e Hints como erros. Uma hora pode explodir um erro na cara do usuário. Se não era a qualidade externa que estaria comprometida, seria a interna (do seu código).
A próxima pergunta seria qual a diferença entre virtual e dynamic. Virtual otimiza a velocidade enquanto dynamic otimiza o uso da memória. Esta diferença é apenas para que usa um compilador Win32. Quem utiliza um compilador num projeto .NET não há diferença nenhuma, já que o .NET mapeia métodos do tipo dynamic em métodos do tipo virtual.
Outra forma de evitar isto seria ao invés de colocar a diretiva override, seria colocar a diretiva reintroduce, em que o método seria reintroduzido, e não daria para acessar o método da classe pai através do inherits.

Espero que tenha dado para aprender alguma coisa! Além da experiencia com classes de cálculo da PPU, utilizei este e este links para escrever este post. Desculpem pelo post longo!

Abraços,
Zé Alexandre