ExtJS e programação funcional Р2

{ January 15th, 2013 }


cmilfont

Autor: cmilfont

[disclaimer]
Os códigos desse post estão no Gist do Github, se não aparece no seu leitor de Feeds vai ter que entrar no site ou ir direto para o github
[/disclaimer]

Continuando a falar sobre programa√ß√£o funcional com o Framework ExtJS, vou avan√ßar sobre a API que fornece fun√ß√Ķes √ļteis para trabalhar sob esse paradigma e quando a abordagem complica a leitura, principalmente para quem n√£o tem tanta intimidade com essa forma de pensar.

Imagine o seguinte Widget abaixo que tem a responsabilidade de plugar uma função para observar o evento busca de outro componente.

Se voce observar atentamente, o mapeamento √© feito um-para-um com uma fun√ß√£o que j√° existe no componente final, inclusive com a mesma quantidade de par√Ęmetros, vimos no artigo passado que bastaria plugar a fun√ß√£o diretamente e controlar o escopo this dessa fun√ß√£o.

Agora imagine que o componente Sorteio tem mais uma responsabilidade no momento que o botão de outro componente for acionado, ele precisaria limpar a área de um terceiro componente, teríamos que voltar o código do primeiro exemplo e fazer aquele mapeamento em um método do próprio componente Sorteio:

Bem, com as fun√ß√Ķes encontradas no objeto Ext.Function podemos mapear diretamente os m√©todos dos respons√°veis principais sem a necessidade de uma terceira fun√ß√£o no objeto Sorteio numa abordagem mais FP aproveitando fun√ß√Ķes √ļteis que encadeam execu√ß√Ķes e retornam outra fun√ß√Ķes com a sequ√™ncia desejada.

A assinatura de colocar um listener escutando um determinado evento é:

this.sorteioform.on("busca", fn, escopo);

Desejamos executar duas fun√ß√Ķes de objetos distintos em uma sequ√™ncia l√≥gica, mas s√≥ podemos plugar uma √ļnica fun√ß√£o por vez. Existe um m√©todo createSequence que fornece esse comportamento desejado, observe:

var fn = Ext.Function.createSequence(fn1, fn2, escopo);

Esse m√©todo gerar√° uma terceira fun√ß√£o com o this dentro dela referente ao escopo passado no terceiro argumento e executar√° as duas fun√ß√Ķes – fn1 e fn2 – na sequ√™ncia indicada.

Poder√≠amos simplesmente encadear as duas fun√ß√Ķes dos dois objetos na assinatura

var fn = Ext.Function.createSequence(this.concorrentes.listar, this.ganhadores.update, this.concorrentes);

Mas tem somente um problema, a fun√ß√£o this.ganhadores.update precisa receber um par√Ęmetro – no m√≠nimo uma string vazia “” – para ter o comportamento adequado.

Existe uma outra fun√ß√£o chamada pass que gera uma outra fun√ß√£o com essa caracter√≠stica, voce pode definir uma fun√ß√£o com valores previamente definidos caso n√£o haja passagem de par√Ęmetros.

var fn2 = Ext.Function.pass(this.ganhadores.update, "");

Dessa forma basta substituir agora a segunda função da sequência por uma gerada com valores predefinidos.


var fn2 = Ext.Function.pass(this.ganhadores.update, "");
var fn = Ext.Function.createSequence(this.concorrentes.listar, fn2, this.concorrentes);

Para garantir que o update executará no escopo de ganhadores, teríamos que definir o terceiro argumento para ganhadores

var fn = Ext.Function.createSequence(this.concorrentes.listar, fn2, this.ganhadores);

E para garantir que o this no listener execute cada função da sequência nos seus contextos corretos voce define o escopo do on para concorrentes
this.sorteioform.on("busca", fn, this.concorrentes);

O resultado final seria um encadeamento das chamadas como podemos ver logo em seguida:

Se voce comparar com uma abordagem mais tradicional verá que nem sempre é mais fácil de ler, portanto é salutar dosar o uso desse tipo de solução.

Posted in Ext, Programação funcional ~ No Comments

ExtJS e programação funcional

{ December 11th, 2012 }


cmilfont

Autor: cmilfont

[disclaimer]
Os códigos desse post estão no Gist do Github, se não aparece no seu leitor de Feeds vai ter que entrar no site ou ir direto para o github
[/disclaimer]

Javascript possui fun√ß√Ķes como tipos de primeira classe na linguagem e implementa v√°rios conceitos de programa√ß√£o funcional, mas essa forma de programar sempre √© relegada quando escrevemos c√≥digo com ExtJS.

Observe no código abaixo um trecho usando ExtJS para expandir as linhas de uma Grid:

Código imperativo comum encontrado nos projetos com ExtJS, o mesmo código conhecendo um pouco a API pode ser feito como se vê abaixo:

Você percebe que utilizando uma abordagem só um pouco mais funcional (como passar função como argumento de outra função) nem sempre vai ter menos código e pode até ser bem maior, mas observando a API com mais atenção você detecta que o método toggleRow pode receber tanto um index quanto o próprio Model, então você abusa mais um pouquinho e passa a própria função como argumento do método each (como podemos ver abaixo).

Comparando os dois códigos você pode até reclamar que a sintaxe imperativa vai ser mais fácil de ler, aí será questão de conhecimento em programação e experiência com essas outras abordagens, reconheço que programação funcional não é comum principalmente para quem programa com ExtJS no cotidiano.

Apesar de tudo vale a pena se esforçar um pouco e começar a escrever um código mais funcional.

Posted in Ext, Programação funcional ~ 1 Comment

Desenvolver em Java em pleno 2012, mesmos erros de 2005

{ February 24th, 2012 }


cmilfont

Autor: cmilfont

Post j√° nasce datado, mas s√≥ faz sentido para agora mesmo. Passei uns 10 anos da minha vida programando na linguagem Java e nos √ļltimos 3 anos eu peguei poucos projetos, mas o que me impressiona nesses poucos projetos √© que as coisas n√£o mudam, inclusive a tara por patterns desnecess√°rios e antipatterns.

Comecemos por Nomenclatura

Se voce chama sua classes de WhateverController, WhateverService e ou WhateverDAO, voce está usando notação hungara desnecessária e complicando a modelagem do seu negócio. Se o seu framework te obriga a nomear as classes com sufixos ou prefixos, ele está errado e é melhor procurar uma solução.

Se voce chama classes como WhateverModel ou WhateverEntity aí voce está estragando a amizade, se mate.

Se voce tem uma classe chamada Whatever e tem propriedades como nameWhatever, leia urgente Clean Code.

 

BOLOVO

As pessoas criavam entidades chamadas¬†WhateverManager por n√£o saberem orienta√ß√£o a objetos, se existe isso no seu projeto na maioria das vezes n√£o tem muito o que fazer, mude de emprego ou de projeto. Mas… se for corajoso comece a refatorar isso guiado por testes, o livro “Growing Object-Oriented Software, Guided by Tests” vai te ajudar bastante. O Paulo Silveira e o Phillip Cal√ßado nomearam esse anti-pattern de BOLOVO.

DAO

DAO √© o pattern in√ļtil quando falamos de neg√≥cios, principalmente CRUD. A n√£o ser que voc√™ esteja codando Framework ou comittando em projetos como o Hibernate, voce n√£o precisa escrever DAO. Voce usa Hibernate, a Session √© seu DAO.

Se voce precisa de uma entidade para agrupar alguma l√≥gica de ORM mais complexa no seu neg√≥cio – como algumas transa√ß√Ķes com rollback l√≥gicos, uma alternativa √© Repository. Mas por favor, leia o artigo do Phillip primeiro e n√£o fa√ßa WhateverRepository. N√£o h√° problema nenhum voce ter Criteria dentro de um controller por exemplo, afinal isso √© um pattern bem estabelecido e o mapeamento um-pra-um com outra entidade s√≥ vai complicar e n√£o traz ganho algum.

S√≥ uma dica aproveitando o tema ORM, o Hibernate trabalha e sempre trabalhou com conven√ß√Ķes usando anota√ß√Ķes, ent√£o n√£o precisa mapear tudo. Basta um @Entity na maioria das vezes. Nos relacionamentos observe se ele j√° n√£o mapeia tranquilo apenas com o @ManyToOne e diminua o ru√≠do.

Em termos de Patterns, por mais caduco que j√° esteja, o PoEAA do Fowler ainda reina.

 

Interface e Implementação

Existe uma boa prática como guia que é desenvolver orientado a interface, só que isso não é lei e deve ser usado o bom senso como sempre. A maioria dos desenvolvedores criam a Interface Whatever e uma Рe apenas uma Рimplementação WhateverImpl. Isso é desnecessário e muita gente nem sabe que o Spring sempre funcionou injetar em classes concretas e não apenas em Interface. Deixe a Interface gritar na sua cara para refatorar.

Service e Domain Driven Design

Aqui que mora o perigo, sempre quando eu vejo WhateverService a implementação dessa classe é o mesmo código do antigo WhateverManager. Depois que Domain Driven Design fez sucesso todo mundo finje que modela o domínio.

As classes do seu domínio devem e podem ter métodos de negócios, se ela apenas tem propriedades é sinal do BOLOVO e representa uma tabela do banco de dados vitaminada. Um Service não é a parte de negócios do seu domain, a grosso modo de explicar o código dele explodiu na sua cara por manipular duas ou mais entidades e não ser responsabilidade de nenhuma delas.

ANUNCIO EM LETRAS GARRAFAIS

Cuidado com os livros que eu indiquei, quando foram escritos o Hibernate e o Spring estavam nascendo ou ainda não tinham nascidos, portanto leia com moderação. Várias coisas já forma implementadas pelos Frameworks e não vá fazer uma roda por cima de outra roda.

TL;DR

Cuidado com o código que voce escreve, faça-o guiado por testes, leia bons livros de Orientação a objetos e Patterns. Não escreva código igual aos outros porque é assim que todo mundo faz.

Posted in Design Patterns, Engenharia de Software, Java, javace, Linguagens, Melhores práticas, Orientação a Objetos ~ 18 Comments