Comments on Rafael rambling: Design Patterns are not Recipes

Very interesting this discussion about PAtterns! T...

2009-04-21T17:45:00.000-03:00

Very interesting this discussion about PAtterns! Thanks a lot for you all! ;-)

Hello! I read this article! Big thanks to author, ...

2007-09-07T11:51:00.000-03:00

Hello! I read this article! Big thanks to author, very interesting. Write more.

"Internacionalizado" que nada... Termos mais adequ...

2007-06-16T03:07:00.000-03:00

"Internacionalizado" que nada... Termos mais adequados são "indeciso" ou "esquizofrenico", com essa alternação inconsistente entre português e inglês (mais certo seria eu manter blogs separados, mas ja tenho dificuldade em levar esse e o da sun; mais um é a ultima coisa que eu quero :). Falando no assunto, acho que já ta na hora de vc abrir um seu, hein?

Vamos por partes, como diria Leibniz:
1) Ainda não encontrei Delegate descrito em forma de padrao, mas eu concordaria com o Iterator e o Observer (muito embora, o observer de margem a uma variedade grande de implementacoes; veja a descricao dele no POSA).
2) Blz.
3)Toda arvore eh um grafo; todo grafo eh um conjunto de arestas, que sao pares ordenados, que tb são conjuntos. Logo toda lista ligada eh um conjunto. Se ela for finita então dá ate para provar que não passa de superconjuntos aninhados do conjunto vazio. Por isso que ciência da computação é diferente de engenharia de software (se é q isso existe). Volto ao intent: uma lista ligada tem a intenção de representar "whole-part hierarchies"? Eu acho que a resposta e não, e por isso trata-la como se fosse um composite não ajuda em nada.
4)Vou deixar o John Vlissides responder essa:
“It seems you can’t overemphasize that a pattern’s Structure diagram is just an example, not a specification. It portrays the implementation we see most often. As such the Structure diagram will probably have a lot in common with your own implementation, but differences are inevitable and actually desirable. At very least you will rename the participants as appropriate for your domain. Vary the implementation trade-offs, and your implementation might start looking a lot different from the Structure diagram.
As for whether one is following the pattern or not, who cares? The pattern is a means to an end, not an end itself. Following it in any strict sense is immaterial. If the pattern solves your problem directly, that’s great; if you have to bend it a bit, that’s great too. Even if the pattern merely inspires you toward an altogether different solution, it has still proven useful. The only potential problem here lies in the documentation phase, when you’re describing your solution in terms of patterns. You don’t want to mislead someone with irrelevant patterns. If you identify a set of classes as adhering to a pattern, make sure they fulfill the pattern’s intent. If the connection is tenuous, don’t mention the pattern; otherwise you’re sure to confuse more than clarify. ”
5 e 6) Vou reler o Decorator e te respondo depois ;)
7) Eu acho que interface em java serve para muito mais coisa do que só implementar o strategy. Primeiro, serve para o State também, que eh quase um padrão irmao. Depois, junto com creation methods*, eh muito util para separar a definição de uma API de sua implementação, tipo os métodos da classe java.util.Collections. Estes são os usos que me passaram pela cabeça agora, mas não tenho duvida que existem muitos mais que não se encaixam bem como sendo “strategies”.

*Que eu normalmente chamaria de factory methods, mas quero eviter confusao com o factory-method do GoF que e um conceito bem mais especifico)

Rafael,

Você é figura cara. E certamente um...

2007-06-15T22:21:00.000-03:00

Rafael,

Você é figura cara. E certamente uma pessoa bem esclarecida sobre o controverso assunto: "design patterns". Sim, sim... Eu mudei muito minha opinião depois da minha última postagem. Mas faço aqui algumas observações, talvez defendendo meu pensamento anterior:
1) Ok! Concordamos que alguns padrões podem vir pré-implementados. Eu arrisco citar Strategy, Iterator, Observer e o Delegate.
2) Outros a receita não ajuda muito como no caso do Prototype.
3) (Mas, e o que eu acho mais interessante é que) eu reforço minha opinião sobre o Composite e as listas ligadas.
(1) Toda lista é uma árvore.
(Um caso particular de árvore onde cada nó possui um único filho.)
(2) Pela intenção, uma lista ligada utiliza uma estrutura em árvore (conforme (1),) para representar a hierarquia parte-todo.
CQD.
Vou adiante: Por (2), posso sugerir uma implementação da "intenção" do Composite em C, dessa forma:
struct node {
struct* node next;
int value;
}
Lindo, né!? Eu fico até emocionado...
4) Agora, faço a seguinte pergunta: Eu devo julgar os padrões pela intenção ou pela "implementação" (isto é, a descrição do Padrão no GoF, "obsessivo" por heranças). Se você me disser que devo julgar pela implementação então a conclusão que chego é que meu tipo node não é um Composite, mas seria do contrário.
5) Como eu disse, acho o GoF obsessivo por heranças. Implementações mais simples satisfazem perfeitamente as intenções propostas. Dou outro exemplo: Decorator
Em java...
public class Component {
}
public class RodrigoDecorator extends Component {
private Component component;
}
Nada de classes "concretas" que herdem de Decorator. Meu RodrigoDecorator já é uma classe concreta. O dia que eu tiver a necessidade de mudar isso, eu refatoro.

6) E qual seria a vantagem de utilizar implementações mais simples para descrever um padrão? Porque assim seria mais óbvio o "padrão". No caso do Decorator, toda utilização de composição + agregação seria um exemplo de RodrigoDecorator. O exemplo complicado do GoF de Decorator também teria um RodrigoDecorator.
7) Claro que continua fazendo sentido dizer que uma Interface específica é um Strategy... É uma forma de comunicar aos leitores daquela Interface que o autor tinha em mente uma seleção de Algoritmos (talvez em tempo de execução). Mas eu acho que seria mais "honesto" validar que Interface é a implementação de Strategy em Java ( afinal, toda vez que você utiliza uma interface, você permite uma seleção de implementações em tempo de execução).

É isso ai!

(Me desculpe poluir seu blog internacionalizado com outro post em português :( )

Oi anonymous. Vamos la, então.

Primeiro ten...

2007-05-20T15:00:00.000-03:00

Oi anonymous. Vamos la, então.

Primeiro tenho que deixar claro que eu procuro refutar a tese "todos os padroes sao templates". Isso nao implica em que eu afirme que "nenhum padrao eh um template". Ao contrario: Iterator, por exemplo, tem uma estrutura bastante rigida e sem muita latitude para o implementador.

Os outros exemplos sao mais complicados. Blocks em Smalltalk facilitam muito a aplicacao do padrao Command, mas dizer que eles "substituem o papel de commands" eh errado. Por um lado, blocks servem para mais coisas do que commands (sao otimos para implementar Strategies, por exemplo). Por outro, as vezes faz sentido programar explicitamente uma classe para o Command, um exemplo, citado no GoF, eh quando se deseja guardar estado no command para permitir Undo. Prototype eh um padrao bastante obvio (o primeiro uso citado eh do Sutherland em 1963!), e, acredito eu, vale mais pela adicao ao vocabulário do que pela estrutura (portanto, nao faz sentido considera-lo como um template). Nisso ele eh similar ao Facade, que eu mencionei no post, e ao Mediator.

Quanto ao Composite, acho dificil que uma lista ligada se encaixe como uma realizacao do padrao. Veja o Intent: "Compose objects into tree structures to represent part-whole hierarquies". A heranca no caso, serve para distinguir o comportamento das folhas dos demais nos, usando polimorfismo para isso. Me parece uma aplicacao perfeitamente adequada de heranca. E "acusar" de obsessao por hereditariedade a obra que tornou famosa a expressao "favor composition over inheritance" eh meio estranho.

[Peco desculpas pelos acentos, problemas tecnicos]

E vamos nós para uma série de "padrões = templates...

2007-05-20T01:44:00.000-03:00

E vamos nós para uma série de "padrões = templates".
Blocks em Smalltalk substituem o papel de comands. Subprojeto commands da Jakarta oferecem commands e chains.
Iterator é uma classe em Java. Prototype é uma implementação de Cloneable com deep copy. O Listener é uma implementação do padrão Observer no AWT/Swing/SWT do Java.

Outros padrões são implementados de uma maneira ou de outra. Por exemplo, qualquer aluno de primeiro de computação esbarra no padrão composite (listas ligadas, árvores, grafos, etc) com a diferença que a implementação pode ou não possuir herança, enquanto que o padrão descrito no GoF usa obrigatoriamente (seria algum tipo de obsessão por heredidade!?).

Só para contribuir um pouco, com meu vastíssimo co...

2007-03-29T01:32:00.000-03:00

Só para contribuir um pouco, com meu vastíssimo conhecimento em inglês.
Já notou que a linguagem java dá de graça o padrão Strategy com interfaces? Que o Java 5 implementa um padrão de metadados que é o annotation. O C# já trás um observer de bandeja. É interessante ver que certos recursos de linguagem não esbarram nos padrões por acidente.