Patterns:Onde?Quando?

Ultimamente nas tópicos que ando acompanhando por aqui e nos livros que ando lendo, tô dando uma atenção especial pra Patterns, OO, e etc.

Acontece que hoje fui atingido pelo zen e obtive iluminação. Na realidade me veio uma questão que nunca havia pensado:
Sei que Patterns são soluções padronizadas para problemas comuns, porém questiono sobre sua utilização. Como vocês usam, ou como é a forma correta de utilização dentro de uma modelagem? Por exemplo, se eu defino que no meu domínio vou usar determinado Pattern, 'terei' de usar ele em todo lugar?Ou somente quando precisar? Eu 'posso' utilizar um Pattern pra solucionar um problema em específico? Posso ter milhares de Patterns dentro da modelagem, sendo que cada uma se adapita melhor a cada situação?

Será que me fiz entender?

Patterns tao aih pra serem usados quando convem, e "quando convem" eh altamente subjetivo, entao cada um aplica a sua propria medida, de acordo com o bom senso.

O balanco entre simplicidade (usar somente os patterns necessarios e nada mais) e consistencia (usar os patterns de maneira homogenea por todo o sistema) eh delicado, e apesar de errar a mao nao ser tao ruim assim, eu prefiro pender pro lado da simplicidade, mesmo que isso complique um pouco pra quem esta passando pelo codigo pela primeira vez (ja que nao tem nada do tipo "ah, todas as views passam por um front controller que fala com um delegate que cria o data transfer object pro data access object passar pro modelo")

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

Uma das coisas que mais valorizo, são os patterns.
Considero soluções realmente eficazes e elegantes, ao contrario de alguns frameworks que tem por ai.
Mas patterns devem ser aplicados com bom censo e não devem ser encarados de uma maneira absoluta. Podem sofrer implemenrações proprias desde que não percam a sua essencia.

Essa é minha opinião.

This message was edited 1 time. Last update was at 04/04/2005 09:54:09

cv wrote: eu prefiro pender pro lado da simplicidade, mesmo que isso complique um pouco pra quem esta passando pelo codigo pela primeira vez (ja que nao tem nada do tipo "ah, todas as views passam por um front controller que fala com um delegate que cria o data transfer object pro data access object passar pro modelo")

Mas desta forma, num futuro próximo não tornaria a manutenção do sistema mais complicada? Se por exemplo alguém diferente de quem projetou ou desenvolveu for dar a manutenção, teria de 'decifrar' o que foi usado antes de encontrar um determinado problema.

Rafael Nunes wrote:Mas desta forma, num futuro próximo não tornaria a manutenção do sistema mais complicada? Se por exemplo alguém diferente de quem projetou ou desenvolveu for dar a manutenção, teria de 'decifrar' o que foi usado antes de encontrar um determinado problema.

Não, por que simplicidade se comunica muito tão facilmente facilmente quanto idiomas conhecidos.

louds wrote:
Não, por que simplicidade se comunica muito tão facilmente facilmente quanto idiomas conhecidos.

Não entedi.

GUJ Expert Membro desde: 12/03/2003 11:25:57 Mensagens: 4680 Offline

E Rafael, como você mesmo disse, patterns são solução comuns. Portanto, não tente aplicar uma solução sem ter certeza absoluta que identificou, analisou e entendeu o problema.
A experiência também trará uma capacidade maior de identificar problemas que virão, tornando possível saber quais patterns serão utilizadas. Mas até lá, sugiro que faça como eu na maior parte do tempo: espere dar errado, depois conserte hehe senão seu código vai ficar muito muito complexo sem necessidade.

jprogrammer wrote:Uma das coisas que mais valorizo, são os patterns.
Considero soluções realmente eficazes e elegantes, ao contrario de alguns frameworks que tem por ai.

O que voce esta tentando dizer aqui? A comparacao entre patterns e frameworks ficou, no minimo, confusa.

GUJ Expert Membro desde: 12/03/2003 11:25:57 Mensagens: 4680 Offline

Rafael Nunes wrote:

louds wrote:
Não, por que simplicidade se comunica muito tão facilmente facilmente quanto idiomas conhecidos.

Não entedi.

O que ele quis dizer é que patterns, ao contrário de soluções caseiras, são um idioma comum entre programadores. Então qualquer um que se preza que leia o código deveria entender pelo menos a idéia logo de cara

Rafael Nunes wrote:

louds wrote:
Não, por que simplicidade se comunica muito tão facilmente facilmente quanto idiomas conhecidos.

Não entedi.

Eh facil, eu juro: dada a escolha entre o codigo mais simples possivel e usar um pattern soh pq todo o resto do sistema usa, eu prefiro a simplicidade.

O resultado final eh que eu acabo com menos codigo, e isso por si so ja reduz o numero de bugs possiveis. A manutencao fica mais facil, pq afinal, tem menos codigo, e entende-lo nao eh nenhuma tarefa monstruosa - afinal, ele ficou simples e curto. Se eu tivesse usado um pattern "so por usar" nao ajudaria em nada, pelo contrario

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

Sei que framewoks e patterns são conceitos diferentes.
Mas são soluções para problemas comuns.
ex:

Hibernate e DAO.
Problema: persistencia.

Embora se possa integra-los ainda prefiro o DAO puro.
Se for feito de uma maneira inteligente fica melhor do que esse hibernate...

GUJ Expert Membro desde: 12/03/2003 11:25:57 Mensagens: 4680 Offline

Hibernate não é um framework para embelezar seu código. Dá para fazer merda com ele do mesmo jeito que com JDBC puro, como por exemplo abrir a sessão no click do JButton e fazer a query.

Agora, se você se acha capaz de implementar second-level cache, lazy initialization de propriedades de beans e jmx para tudo quanto é lado das suas DAOs, meus parabéns, pois eu nem saberia por onde começar. Que tal deixar o preconceito de lado e pelo menos testar ele?

This message was edited 1 time. Last update was at 04/04/2005 11:39:23

Transação eu passo a responsabilidade para o banco.
(commit rollback)

Lazy load (nada de mais). Nada que uma collection personalizada não resolva.

Cache
Um pode ser o grande trunfo, se necessário.
Mas...
Como o cache pode me ajudar em aplicações em que eu atualizo e recupero informações contantemente do banco. Melhor cache no consumidor de dados não no fornecedor.

GUJ Expert Membro desde: 12/03/2003 11:25:57 Mensagens: 4680 Offline

jprogrammer, eu falei

me wrote:lazy initialization de propriedades <<<

E, mesmo sobre collections, você acha simples implementar essa "collecion personalizada"? Colocar código de acesso a dados dentro da classe não vale hehe.

E eu nem falei sobre transações @.@

Concordo sobre cache no cliente, mas me diz como você faz isso caso seja uma aplicação web, guarda um array e monta as listas com JS? Já tentei, o browser trava

. E, mesmo com uma grande carga de atualização e inserção, sempre há dados que merecem ficar no cache.

E na boa, só por ele escrever as queries para mim, na linguagem de qualquer banco relacional, já compensa o jarzinho de 900kb. Ou você ainda obriga o seu cliente a comprar qualquer coisa que seja?

Levanta a mao quem sonha em um dia ler o codigo do jprogrammer!

* cv se joga no chao *

Cara, tudo bem querer fazer o seu. Eu acho o maximo quando eu estou estudando alguma coisa e consigo fazer tudo no braco. Eh legal, quando a gente ta estudando.

Agora, nao usar uma ferramenta prontinha que ta so esperando pra resolver os mesmos problemas que voce ta implementando na unha, depois que voce ja sabe como fazer, so tem um nome (que eu vou omitir, pra te deixar pensando no assunto, e nao eh o tipo da coisa de que se chamaria uma velhinha na rua).

Vou chamar isso de "Complexo de Saoj", outro usuario aqui do GUJ que chama qualquer tentativa de se usar um framework consolidado e adorado pela comunidade Java de "tentar acabar com a criatividade".

Pessoalmente, depois que eu li algumas coisas do codigo do Hibernate eu fiquei pensando que se eu fosse um pouco mais lerdo, iam ter que me aguar duas vezes por semana. Tem coisa ali que simplesmente NAO DEVE FAZER PARTE DO CODIGO DE UMA APLICACAO JAMAIS, e deve ficar escondida em JARs que soh os nerds mais corajosos dos nerds mais corajosos precisam chegar perto.

Resumindo a coisa toda em uma pergunta: pra que voce gosta de se matar - e matar a sua equipe - desse jeito?

Notícias, artigos e o maior fórum brasileiro sobre Java