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?
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”)
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.
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.
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.
[quote=jprogrammer]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.[/quote]
O que voce esta tentando dizer aqui? A comparacao entre patterns e frameworks ficou, no minimo, confusa.
[quote=Rafael Nunes][quote=louds]
Não, por que simplicidade se comunica muito tão facilmente facilmente quanto idiomas conhecidos. [/quote]
Não entedi.[/quote]
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
[quote=Rafael Nunes][quote=louds]
Não, por que simplicidade se comunica muito tão facilmente facilmente quanto idiomas conhecidos. [/quote]
Não entedi.[/quote]
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
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?
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.
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! :mrgreen:
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?
Existe uma boa razão pra isso: Garantia do Emprego Através da Obfuscação Manual de Código Fonte. Agora, se não for esse o motivo, isso simplesmente diminui o tempo do prazo, gasta dinheiro do projeto e gera consultoria pra gente
Pensando bem, eu devia ter ficado quieto, ne? :mrgreen:
Mas, falando serio, gera consultoria, pq afinal um projeto que implementa o seu proprio Hibernate, Struts ou outro framework web so tem um destino: meses de retrabalhos, consertos fantasticos e remendos mirabolantes. Pode nao acontecer durante a duracao do projeto, mas se a estimativa de vida do software eh de mais do que alguns meses, eh soh questao de tempo…
Fico me perguntando o quanto a nossa profissao evolui com esse tipo de coisa. :roll:
Pensando bem, eu devia ter ficado quieto, ne? :mrgreen:
Mas, falando serio, gera consultoria, pq afinal um projeto que implementa o seu proprio Hibernate, Struts ou outro framework web so tem um destino: meses de retrabalhos, consertos fantasticos e remendos mirabolantes. Pode nao acontecer durante a duracao do projeto, mas se a estimativa de vida do software eh de mais do que alguns meses, eh soh questao de tempo…
Fico me perguntando o quanto a nossa profissao evolui com esse tipo de coisa. :roll: [/quote]
Evolui para HGGOO - Hiper Grandes Gambiarras Orientadas a Objetos
Não estou falando que devemos criar tudo do zero.
Acho o hibernate uma ferramente bem interessante, mas para determinadas tarefas é bem mais interessante criar implementações proprias.
Não acredito nessa de criar implementações proprias gera bugs e retrabalho.
Depende do nível de complexidade.
Os padrões da SUN já nos dão bastante suporte para criarmos soluções com qualidade.
Desde que eu programo em VB sempre criei minhas proprias OCX e DLL’s
para facilitar minha vida. Mas não quer dizer que fazia isso escovando bits.
Usava quando apropriado bibilotecas já prontas e testadas.
No java é mesma coisa.
Agora, se não for esse o motivo, isso simplesmente diminui o tempo do prazo, gasta dinheiro do projeto e gera consultoria pra gente