Ensaios Noturnosensaios porque não passam de tentativas de bons posts... noturnos porquem as idéias geralmente chegam quando estou prestes a dormir...o que inclusive me irrita, pois sou obrigado, diversas vezes, a levantar e anotar para um futuro desenvolvimento da idéia

A segunda pattern explicada no livro Design Patterns é o builder. Ela é muito parecida com a pattern AbstractFactory explicada no post anterior, mas ela possui um foco diferente.

O intuito desta pattern é separar o processo de criação de um objeto da sua representação. Assim, um objeto complexo, que exigiria algumas etapas para sua construção, pode ter um builder genérico que serviria para diferentes representações desse objeto.

O exemplo utilizado no livro é de um leitor de formato RTF. Esse leitor pode criar uma outra representação do formato RTF de várias maneiras: em puro texto, em formatação alternativas como o LeX, ou até em representações gráficas. Cada uma dessas representações é um produto distinto, mas, em todas elas, o processo de conversão a partir do RTF analisaria o texto sequencialmente, e executaria processos especiais para coisas como: mudança de fonte, mudança de parágrafo, inserção de caracteres especiais e etc.

O diagrama de classes abaixo ilustra como é a solução oferecida por esta pattern.

Na ilustração não está o papel do cliente. O interesse do cliente é obter um Produto. Para isso ele precisará ter conhecimento do Diretor (genérico) e do Builder, mas reparem que o Cliente precisa conhecer o builder concreto e não apenas o abstrato. Isso porque o método GetResult não está declarado na interface Builder.

Esta pattern, portanto, torna o seu sistema dependente do produto final. O que a pattern vai abstrair é o processo de criação do produto, guiado pela implementação do método Construct pelo Diretor (que vai construindo as partes do produto, sem precisar conhecer sequer qual é a interface do produto).

É decisivo nesta pattern a escolha de um processo de criação do produto com uma granularidade fina o suficiente para a criação das diferentes representações do Produto. Isso pode ser um problema para alguns dos builders concretos mais simples, que necessitem implementar várias partes vazias desse processo. Um jeito interessante de se fazer o Builder para evitar isso é através de métodos BuildPart vazios, para que os builders concretos implementem apenas os processos que lhe são interessantes.

Eu confesso nunca vi esta pattern em ação, mas fazendo uma comparação com a AbstractFactory vejo duas diferentes:

1. O builder está focado na construção do objeto na forma de passos (partes)
2. O cliente fica dependente da classe concreta do builder (não é um defeito, a pattern foi feita propositadamente desta forma, a intenção era permitir diferentes conjuntos de construção e representação para um produto conhecido)

Patterns Criacionais

A Abstract Factory é a primeira Design Pattern descrita no livro Design Patterns. Ela faz parte da categoria de Patterns Criacionais, cujo objetivo é a instanciação de objetos. Essa categoria é importante pois ela sustenta o princípio mais importante do livro: “programe para interfaces e não para implementações”.

Todas as patterns tratam a respeito de relações entre os objetos, de forma que eles sejam independentes das implementações. Porém, em algum momento esses objetos deverão ser instanciados, e aí entram em cena as Patterns Criacionais, cujo único objetivo é a instanciação de objetos de forma que seu sistema continue independente de implementações.

Posso dizer que, atualmente, essas patterns criacionais estão em desuso, sendo substituídas pelos frameworks de Injeção de Dependência, que fazem exatamente isso: instanciam para você as classes das quais você é dependente. De toda forma, conhecer as patterns, a sua motivação e entender as suas consequências é um bom exercício de design de software.

Abstract Factory

O problema específico que a AbstractFactory tenta resolver é da instanciação na existência de uma família de produtos. O exemplo dado no livro é o seguinte: você tem elementos visuais (produtos), como Window, ScrollBar, Menu e etc. Esses elementos visuais têm diferentes implementações para cada família de implementação gráfica, como o Microsoft Windows, o MAC, e X do Linux.

Nesse caso, a solução consiste de duas coisas:

1. Crie interfaces padrões para os diferentes produtos dessa família (como Window, ScrollBar e Menu). E todo o seu sistema vai trabalhar apenas com essas interfaces que você definiu.

2. Defina uma AbstractFactory, que tem os métodos de instanciação para cada uma dessas interfaces padrões definidas acima, no caso, os métodos para o exemplo seriam: CreateWindow, CreateScrollBar, CreateMenu. Toda hora que o seu sistema precisa de instâncias dos produtos ele as obterá através dessa AbstractFactory.  Algo como factory.CreateWindow()

Mas de onde virá essa factory? Em algum lugar, provavelmente na inicialização do seu sistema, você define qual AbstractFactory você vai fornecer ao seu sistema, e repassa essa factory a todos os objetos que precisarem dela.

Na figura acima, retirada do livro, o Client, que representa o “resto do seu sistema”, utiliza as classes abstratas dos produtos (AbstractProductA e AbstractProductB) e a AbstractFactory, assim como foi explicado.

Prós x Contras

É importante agora analisar os benefícios e malefícios dessa pattern. O ponto principal é que a pattern deixa seu sistema independente das diferentes famílias, ou seja, garante o baixo acoplamento que foi falado no começo.

Outro ponto positivo é que a pattern permite adicionar, remover ou modificar rapidamente qual família de produtos deseja-se usar. Isso pode até ser feito em runtime, se usado com um pouco de Reflection.

O ponto negativo desse pattern é que a adição ou remoção de um produto da família exige a modificação da AbstractFactory, o que causa um grande overhead, pois deve-se modificar todas as implementações da factory e o cliente que usa a AbstractFactory.

Na verdade, usando-se Reflection pode-se até criar um único método “Create” que recebe como parâmetro alguma indicação de qual produto ele deve criar (uma string com o nome da classe, por exemplo). Assim, você poderia criar um novo produto sem muitos problemas, basta passar o parâmetro certo para o novo produto. Mas isso funciona como uma balança: se você ganha flexibilidade na criação de novos produtos, você perde com a necessidade de uma interface única para todos esses produtos, já que eles serão retornados pelo mesmo método “Create”.  E o seu client precisará fazer um cast para o produto certo.

Para estrear a série “Resumo dos clássicos da computação” começarei pelo consagrado Design Patterns, escrito por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides.

O livro Design Patterns é um dos maiores, se não o maior, dos clássicos em desenvolvimento de software. Seus autores ficaram imortalizados como “a gangue dos quatro”.

O primeiro capítulo do livro serve para explicar o que são Design Patterns. Traduzindo o termo para o português teríamos “Padrão de Projeto”, uma tradução bem razoável. As design patterns são padrões desenvolvidos para sistemas orientados a objetos (conhecer OO é requisito mínimo para ler este livro).

As design patterns não foram inventadas pela gangue dos quatro, o trabalho deles foi identificar e catalogar esses padrões de projeto usados em diferentes sistemas em operação pelo mundo. Eles identificaram esses padrões, as situações em que eram usados e ainda vantagens e desvantagens do uso de cada padrão. Esse catálogo que fez do livro um clássico: ele virou referência para análise de qualquer outro sistema.

E afinal, o que é uma design pattern? Design pattern é uma forma de se estruturar os objetos do seu sistema OO para resolver um tipo de problema recorrente. Assim, a mesma design pattern pode ser usada para diversos casos distintos, desde que  apresentem algumas características em comum, encaixando-se no “tipo de problema” para o qual a pattern foi concebida. As designs patterns são comumente encontradas nos grandes sistemas implementados com sucesso pelo mundo afora.

Para caracterizar uma Design Pattern, ao longo do livro, eles utilizam:

1. Nome – para podermos nos referenciar de forma fácil a elas

2. Problema (ou “tipo de problema” ou “situação”) -  uma caracterização de quando essa pattern deve ser usada

3. Solução – é a estruturação dos objetos de forma a resolver o problema acima descrito (quais as interfaces, como elas se relacionam e suas funções na resolução do problema)

4. Consequências – são as vantagens e desvantages da pattern, ou resultados obtidos com o uso daquela pattern

Dois conceitos fortíssimos ficam ao longo de todo o livro:

- Programe para interfaces e não para implementações, deixando seu sistema com baixo acoplamento

- Abtraia os conceitos que variam no seu sistema em forma de objeto. Por exemplo, se você tem um objeto que possui alguma lista, e em algum  momento esse objeto deve ordenar essa lista, mas existem vários parâmetros que alteram a forma com a qual essa lista deve ser ordenada, então, uma boa idéia seria criar objetos para as diferentes formas de se ordenar essa lista.

Os capítulos do livro descrevem, cada um, uma Design Pattern. Nos próximos dias criarei posts para cada uma dessas Design Patterns apresentadas no livro.

depois do incrível lançamento do NiceTranslator para Opera, a Ruppel & Ruppel Associations of Engineers volta com mais uma novidade que vai revolucionar o mercado de scripts alternativos para browser também alternativos

O LongUrl, no firefox com versões em forma de extension e GreaseMonkey, também foi portado como User Javascript para Opera, link abaixo:

LongUrl for Opera

para quem não sabe, o LongUrl traz de volta à sanidade à nossa querida internet, ao descobrir para onde essas “Short Url’s” levam (sabem aqueles links estranhos começando com bit.me, migre.me e etc? que qualquer um pode mascarar um link malicioso e te enviar? e que já são ruins pelo simples fato de você não poder sequer prever o que te espera no link)

pois bem.. esses links popularizados pelo twitter são tratados com dignidade pelo LongUrl… um verdadeiro descobridor de destinos de links estranhos =)

façam bom uso!

e então eu volto a usar o Opera… pq o consumo de memória do firefox começa a me incomodar (ainda preciso testar isto aqui)

mas aí, as extensões do firefox começam a fazer falta…

uma que gosto muito é o nice translator, que faz a tradução “inline”, sem sair da página

e eis que acabo de terminar o “port” dessa extensão para o Opera!

e devo dizer que deu um trabalho do cão!

mas está feito! o pacote completo exigiu a “instalação” do jquery, e de dois scripts para permitir XMLHttpRequest em Cross-Domain

Podem baixar o arquivo aqui: nicetranslator_opera

O zip contém 4 arquivos javascript que devem ser colocados na pasta de User Javascript do Opera (configurado em Ferramentas->Preferências->Avançado->Conteúdo->Opções Javascript).

English version:

I have just made this port of “Firefox NiceTranslator” to work with Opera, in the form of User Javascript.

The download link is here. It contains the Nice Translator script (ntff.js) and also 3 more files: the jquery library and 2 files to allow User Javascript Cross-Domain XMLHttpRequest (from here)

To install, just put it in your user javascript folder (configured at Tools->Preferences->Advanced->Content->Javascript Options).

ps: you can add it to the context menu with this line:

[code lang="php"]Item, "Translate"="Go to page, "javascript:ntff.openTranslator(ntff.getBrowserSelection());""[/code]

hoje passei por uns mal bocados para conseguir o glorioso compartilhamento de arquivos entre windows xp e vista

ao invés de sair praguejando, resolvi compartilhar os conhecimentos adquiridos hoje

abaixo, as etapas necessárias para compartilhar arquivos entre xp e vista. Deixei as coisas muito simples, apenas como referência, detalhes podem ser encontrados no link no fim do post)

1. Tenha certeza de que estão no mesmo grupo de trabalho

2. Verifique o firewall do xp e o centro de compartilhamento do vista (para saber se o compartilhamento é uma exceção do firewall e se o compartilhamento está ativado, respectivamente)

3. Verifique acesso fazendo ping de um computador para outro

4. Compartilhe as pastas!

Esta última etapa de compartilhamento tem uma dica importantíssima para evitar o famigerado: “xp acessa vista mas vista não acessa xp”

Primeiro que o compartilhamento no xp não poder ser do tipo “simples”.

Segundo que se você não quer usar os mesmos usuários em vista e xp, deve fazer uma etapa adicional ao compartilhar a pasta no xp: Após chegar na aba de compartilhamento e marcar a opção “compartilhar pasta”, você também deve ir na aba “Segurança” e adicionar o grupo de usuários “Todos” para ter acesso de leitura (normalmente ele só vai deixar os usuários que estão no Windows XP com permissão)

Aliás, muita gente coloca como etapa para compartilhamento entre xp e vista a criação dos mesmos usuários nos dois computadores, o que considero agora uma má recomendação. O ideal é explicar que a criação dos mesmos usuários facilitaria, pois por padrão o XP já deixa as permissões de leitura para os usuários cadastrados nele.

Detalhes das etapas podem ser encontrados aqui. Exceto esse truque da aba “Segurança” que eu descobri sozinho depois de rachar a cuca…rs

eu gosto mais de atualizar e incrementar a minha instalação do wordpress do que criar posts, já estou certo disso

na sexta, blog atualizado para a versão 2.8

e hoje coloquei o glorioso code snippet, para, no caso de necessitar escrever códigos, eu possa fazê-lo sem maiores dificuldades

e a grande feature é ter numeração das linhas e mesmo assim poder fazer Ctrl+C Ctrl+V

[code lang="java"]
void teste(){

int a = 0;
teste.start();
for(a = 0; a < 5; a++)
doSomethingSpecial();

return a;
}
[/code]

hahahaha q nada a ver… soh testando mesmo

na engenharia fala-se muito em “soluções de problemas”

e frequentemente um determinado problema tem uma solução chamada “genial”, ou seja, uma solução que custa pouco e resolve o problema de forma inteligente

mas, existe um aspecto que foge um pouco ao senso comum: também frequentemente ocorre da solução “genial” não ser a melhor solução!

isso porque as soluções geniais geralmente são díficeis de serem compreendidas ou modificadas, e como na engenharia os problemas mudam constantemente, esse é um requisito quase fundamental

procurava um bom tema a estudar, para formar minha tese, para guiar minha vida

resolver o trânsito de uma cidade, me parece realmente das coisas mais desafiadoras

a primeira idéia que tive, seria fazer o que o Minority Report mostra… carros que andam sozinhos numa velocidade absurda, mas que precisam andar sobre uma pista especial, espécie de trilho

More »« Less