Patterns:Onde?Quando?

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.

Essa é minha opinião.

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:

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

Não entedi.

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:

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.

Rafael Nunes:

louds:

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

Não entedi.

Rafael Nunes:

louds:

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

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…

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.

jprogrammer, eu falei

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

Ta parecendo até um pokemon :lol:

Pessoal, não falem tão mau assim de JDBC puro!

Para que seu sistema seja portável entre vários SGBDS é algo bastante simples de se implementar!

É só criar uma Abstract Factory, um Factory Method para cada SGBD e um DAO para cada classe persistente vezes a quantidade de SGBD’S

Vamos fazer umas continhas!

Vamos usar por exemplo MySQL, Oracle, DB2, Postgre, Firebird e Access!
Eu tenho no meu sistema 16 classes que precisarão ser persistidas, não é???

Agora vamos fazer as continhas, que são muito difíceis!!!

6 (número de SGBD’s) X 16 (classes persistentes) = 96 DAO’s!!

Viche, 96 DAO’s!!!

Será que alguém poderia fazer uma continha para saber quantos dados seria necessário criar no Hibernate para implementar 6 SGBD’s???

Acredito que esta conta deve ser bém mais difícil!!! :lol: :lol: :lol: :lol:

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.

tipo, você criou um jprogrammer-lib.jar!!!???

Legal isso, realmente pra você fica mais fácil!!

Mas o problema é quando você faz isso e essa solução já foi criada e já é extensivamente usada por outros programadores!!!

Suponha que vc criou uma super-jprogrammer-lib.jar, e você sai da empresa para trabalhar em uma empresa melhor, daí o seu substituto nem imagina como usar sua lib e ainda por cima mete a faca em você dizendo que você poderia usar tal solução open source que já é basntante conhecida no mercado!!!

Você consegue garantir que todos consigam realmente usar e sem dificuldades a sua super-jprogrammerlib.jar???

Então disponibilize ela pra gente ai…!!!

ehehe!!!

1 - Isso com certeza nunca seria uma decisão minha sozinho.
2 - Para que existe documentação ?

Acho que é inteligente você ter bibliotecas próprias para reuso.
Já conheci empresas em que chegavam mais longe desenvolvendo seu proprio IDE e até pasmen “LINGUAGEM PRÒPRIAS”.
Existem sistemas no mercado que funcionam a partir de regras de negócio implementadas a partir do usuário.

Não é errado adaptar ferramentas para necessidades especificas.
É lógico depende muito o tipo de necessidade que você tenha.
Agora me fale se e possivel eu aplicar um hibernate da vida ou strus facilmente em um tipo de aplicação como essa ?
Se você é uma software house que possue sistemas padronizados e não projetos sob encomenda não seria mas produtivo implementar soluções mais especificas ?

Sim. E você faria isso estendendo as soluções de mercado, não substituindo.

Sim com certeza. Ninguém quer reiventar a roda.
Mas se uma implementação própria se encaixa melhor, é inteligente usa-la.

Por isso é interessante programar por interfaces não por implementações.
Se for necessário mudar é bem mais fácil. É aí que entram os patterns.

É melhor você ter.

class Utils{
   public static String hoje()
   {
       return Formata(Calendar.getInstance().toString());
    }
}

Utils.hoje();

do que

Formata(Calendar.getInstance().toString());

Outra coisa por ex:
Você tem uma aplicação em que o usuário cria campos em run time. O hibernate seria uma boa ?

Depende. Se for um meta banco, por que não? Agora, se o usuário cria campos “físicos” na tabela, você também não tem problemas com as classes que representam isso? E implementar as interfaces do Hibernate para suportar isso, como EntityPersister, não seria mais fácil? O Hibernate normalmente é flexível o suficiente para esses casos “estranhos”.

Reconheço que as vezes a falta de conhecimento em uma ferramenta faz a gente criticar antes de conhecer…
Mas sempre procuro manter um sistema indepentente de uma ferramenta na medida do possível. Daí a necessidade dos patterns.

Pattern DAO. Muito bem sacado.
Agora chamar o session.save direto é suícidio.

dao.create() não pode ser um suicídio???

O suicídio não depende do mercanismo de persitência, e sim da competência do programador!!!

Abraços!

Sim realmente não depende.
O problema principal não é a implementação, mas sim a interface exposta pelo programador.
Se não for flexivel pode custar caro.
ex:
Concordamos que o hibernate é hoje a melhor solução de persistencia.

você tem.
session.save explado no sistema inteiro.

um belo dia muda para hibernate 10, 11, XYZ…

se você tiver
DAO.save, precisa apenas mudar em um único ponto.

Isso deve ser valorizado. Os programadores criarem arquiteturas inteligentes. Tecnologias por traz são muito importantes, mas são substituiveis…

Hibernate suporta o mecanismo predileto de 9 entre 10 desenvolvedores “enterprise”… HashMap

Ou seja, se você acha que esse negocio de POJO é muito inflexivel e exige muito código, o Hibernate te permite mapear as entidades em gloriosos HashMaps. Gloria gloria aos maravilhosos softwares e frameworks que usam o incrivel paradigma “HashMap oriented software development”.

E quanto a usar soluções caseiras no lugar de frameworks que sabem oque fazem. Bom, eu sou 100% simpático ao argumento do mister_m. Estenda eles, não substitua. Com um pouco de esforço, geração de código e umas classes de apoio, você consegue enlatar boa parte do processo de escrever software crud.

Fora isso, escrever software de infraestrutura, como hibernate, é algo completamente diferente que software para um usuario final.

Vejo varios lugarem que fazem diariamente essa escolha “esperta” e quase sempre o motivo é garantir o emprego de cada um.

Acho que você não entendeu que é possível fazer algo como:

interface Dao {
    public void save( Object o );
}

class JdbcFromHellDao implements Dao {
   public void save( Object o ) {
      // descobre qual objeto que é, procura por algum tipo de
      // mapeamento para saber quais são os atributos e quais são as colunas
      // da tabela, usa SPCSPL para montar a query,
      // faz a conexão, cria o prepared statement, popula o ps,
      // executa a query
   }
}

class HibernateDao implements Dao {
      public void save( Object o ) {
         session.save( o );
      }
}

Apesar de ter feito questão de dar uma pinicadinha em jdbc puro (hehe), o que quis mostrar mais uma vez é que Hibernate e DAOs não tem necessariamente nada a ver um com o outro. Quem quiser usa junto oras

E mais um detalhezinho: o Hibernate será muito em breve um padrão da Sun. EJB3 vai usá-lo para fazer a persistência dos EJBs.

É isso mesmo que eu gostaria de dizer.
Já que o hibernate hoje é a melhor solução, mesmo que não agrade gregos e troianos, que se faça de uma maneira inteligente (junto com o DAO).

Porque o Thiago falou que DAO.create é suicidio.
É melhor que session.save direto.

Lipe,
Hoje então você chama o session.save() direto nos seus objetos do domínio?
E se acontecer de mudar a forma de persistência, se por exemplo quiser mudar de Hibernate pra Entity?

jprogrammer:

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.

Implementacoes proprias adicionam complexidade extra ao software. Quanto mais complexidade, mais bugs, e quanto mais bugs, mais retrabalho. Voce pode nao acreditar num fato, mas ele vai continuar existindo

Os “padroes da Sun” (que nao sao da Sun ;)) dao suporte para se construir software no modelinho da J2EE, e muita gente ja deu de cara na parede por achar que isso era tudo que precisava. Imagino que isso nao tenha acontecido com vc ainda, entao talvez vc ainda esteja em tempo de ler de novo essa thread e repensar umas coisas. Nao que eu esteja metendo o bedelho no seu trabalho ou no jeito que voce escreve o seu software, mas eu me importo com isso a partir do momento que eu me imagino dando manutencao ou fazendo algum refactoring numa app dessas.

Rafael Nunes:

Lipe,
Hoje então você chama o session.save() direto nos seus objetos do domínio?
E se acontecer de mudar a forma de persistência, se por exemplo quiser mudar de Hibernate pra Entity?

Cv pode criticar a vontade. Quero aprender e estou aberto a críticas.
Sim estou considerando tudo que o pessoal está escrevendo.
Não quero reiventar a roda, mas também não quero ser o programador limitado e preguiçoso.

Tudo deve ser baseado no bom censo.
Sei das minhas limitações (são muitas), sei o que é viável para realidade, mas ter criatividade e personalidade é bem interessante.
Já houvi muita gente falar.
Bom use o struts pois todo mundo usa.
É o mesmo que você falar. Use o windows, todo mundo usa.

É lógico que você tem garantias como suporte, documentação experiências, know-how. Mas se não se encaixa perfeitamente.

Mas ter um monte de coisas para usar uma.
Não é mais fácil eu usar uma servlet e dar uma request dispatcher para um JSP.

O que isso tem de errado.
A simplicidade. Não vejo nenhum retrabalho nisso.

Qualquer implementação posterior tenho RequestWrappers, Filters, etc. Um monte de padrões…

Ah, entendi o contrário, é daquele jeito que você faz então? Porque é assim que eu tô fazendo, vi seu post e já tava pensado: ‘Que merda que eu fiz dessa vez?!?’…

jprogrammer:

Bom use o struts pois todo mundo usa.
É o mesmo que você falar. Use o windows, todo mundo usa.

Isso significa que existe o jprogrammer OS™ ? :mrgreen:
(afinal de contas nao precisamos de tanta coisas que os SOs fazem, suporte a drivers e essas coisas, podemos escrever só pro nosso hardware e tá tudo certo, funciona que é uma beleza.)

• Samuel que nao tem nada pra fazer e queria postar neste tópico *

O cara se tá de sacanagem.
Eu quero fazer uma analogia.
Quem você acha que é melhor ?
Windows X Linux.
A maioria usa Windows, mas realmente é o melhor ?

E não quero escovar bits em minhas implementações.
Não quero substituir o hibernate ou struts. Mas prefiro usar que tem de padrão nativo.
Junto com patterns de desenvolvimento eu consigo coisa melhor que com alguns frameworks para DETERMINADAS NECESSIDADES.

Agora pergunta as grandes e médias companias de software (PEOPLESOFT, SAP, MICROSIGA, DATA SUL) se eles usam struts ou hibernate. Eu sei que alguns usam JAVA e J2EE. Pois são sistemas padronizados e não sob encomenda. Acredito que para as Consultorias de encaixam ferramentas mais genéricas.

Podemos perguntar para umas empresas maiores, tipo IBM… que usa Struts por tudo quanto é canto.

Sim em web sites, portais acredito que struts de de muito bem.
Mas em sistemas ERPs altamente configuráveis…

Yeah, usam sim.

Bem, a pequena Borland usa Struts, a Sun tb usa Struts e mais que isso, baseiam suas soluções nele (e outros projetos Open Source, incluindo frameworks) …

Usando o Hibernate temos AT&T, PriceWaterhouseCoopers, Cisco e mais um punhado …

Mais uma vez, Design Patterns não tem nada a ver com frameworks, em geral um framework emprega um punhado de design patterns para solucionar nossos problemas.

O que o povo tá tentando te explicar é que, em geral, é uma péssima idéia desenvolver uma solução própria sendo que existe um framework que já é testado e aprovado para solucionar o seu problema, mesmo que seja extendendo-o.

Sim. vou considerar melhor essa opção de extensão…
Complementando…

Mas é facil eu refletir o modelo de dados do hibernate em uma aplicação struts ?
vou explicar:

eu tenho o campo código do funcionaário em várias telas.
esse campo tem o tamanho de 10 posições.

<input type='text' name='codigoFunc' maxlength='10' >

Mas um belo dia eu mudo para 15. como eu reflito isso de uma maneira elegante.

jprogrammer:

Sim em web sites, portais acredito que struts de de muito bem.
Mas em sistemas ERPs altamente configuráveis…

A maioria desses sistemas que custam $0.01 para adquirir e $1 zilhão para customizar datam bem antes do Hibernate ou Struts.

jprogrammer:

Sim em web sites, portais acredito que struts de de muito bem.
Mas em sistemas ERPs altamente configuráveis…

Os produtos Oracle sao beados no ADF :shock: que usa Struts :shock: .

jprogrammer,

Na boa, escuta os conselhos do pessoal que tu vai te dar muito bem.
Eu ja passei por isso, ja comentei em outro topico. Meu primeiro trabalho com Java era dar manutencao em um portal que foi feito por uma SH. O sistema foi feito ± em 1998 usando uma arquitetura interna deles.
Nao queira pegar um carinha desses pela frente.

Acredito que a melhor maneira de tratar isso é criar um, hm digamos padrao de desenvolvimento usando os melhores frameworks para cada caso, mas sempre abstraindo eles (entenda-se escondendo eles) para se algum dia precisar mudar nao se perca muito tempo.

]['s

fabgp2001 eu estou gostando dessa ideia de extensão. Legale acredito que muitos que estão lendo essas mensagens estou gostando dessa ideia.
Independencia sem esforço !
Bem melhor que começar do zero !
:lol:

Quase, Fabio… uma coisa que eu tou vendo todo mundo bater boca nessa thread mas que ate agora nao me convenceram direito eh esse papo de “abstrair o framework”…

Custa TAO caro assim trocar um Hibernate ou Struts por outra coisa, que justifica ficar pensando em esconder o framework como se fosse doenca venerea sem realmente saber se vc vai ter que se livrar dele um dia?

Alguem aqui ja teve que fazer uma migracao dessas, e esconder o Hibernate nos DAOs ajudou alguma coisa, ou soh atrapalhou o progresso te impedindo de usar as APIs mais avancadas como a Criteria, pq ela teria que ser usada em lugares “puros”, e te deixando com o minimo divisor comum da historia?

Lógico que custa caro.
Imagine um sistema com 750 telas com ± 900 entidades. Já vi uma de folha de pagamento que tinha isso. Apenas folha, Imagine um ERP.
É lógico de deve-se adotar uma técnologia difinitiva. Ninguém vai pensar estou usando hibernate mais talvez amanhã eu uso XYZ.

Mas melhor previnir do que remediar.

Agora aquela perguntinha que eu fiz de integrar o modelo hibernate com
interface gráfica é possivel ?
O exemplo de tamanho de campo é apenas a ponta do iceberg.

Depende. Só se probabilidade de ter que remediar x custo de remediar >= custo de não prevenir.

É obvio. Sempre o bom censo.
ex:

Tenho um cadastro em uma página para um evento que irá acontecer essa semana e nunca mais vai acontecer.
Para esse caso não vale a pena mesmo.

“Logico que custa caro!” nao eh uma prova la muito boa, jprogrammer. Quanto custa o trabalho de isolar o framework comparado com o custo de usar ferramentas de refactoring boas pra mudar a implementacao caso isso um dia seja necessario?

Note que, na primeira situacao, o custo eh maior que o risco, mas nao quer dizer que o risco nao exista: voce soh tah arriscando outra coisa, que eh a de nao usar tudo que o framework tem pra oferecer e acabar empacando, ou tendo que aumentar a complexidade do software por causa disso.

Eu discordo, aliás, é exatamente isso que estou fazendo.
Estou desenvolvendo uma aplicação aqui em que as classes de negócio conversam com um DAO e este com o Hibernate. Fiz dessa forma pra se um dia quiser trocar o Hibernate por Entity ou outra forma de persistência, fique sem maiores dores de cabeça.

Prevenir a substituição de um framework só faz sentido se ele for proprietario e a empresa dona falir.

Caso seja open source, muito mais facil e barato mantem um fork local que abstrair ele em todo canto.

Eu já fui por esse caminho e hoje vejo que foi um enorme burrada.

Ai voltamos para a excelente pergunta deste topico.
Re: Patterns:Onde?Quando?

Os patterns são usados principalmente para dar elegancia ao software e reusabilidade dentro da própria aplicação sem uso de ferramentas externas e geradores de código.

Se for para usar isso tem:

e-gen (free)

genexus (gera para várias linguagens)

Compuserve Uniface (também gera para várias linguagens).

louds:

Prevenir a substituição de um framework só faz sentido se ele for proprietario e a empresa dona falir.

Hmmm, mesmo que ela não venha a falir… É impressionante o que os vendors são capazes de fazer de uma versão pra outra mesmo que você seja premium customer…

jprogrammer, eu uso padrões o máximo que posso, mas sempre seguindo as seguintes regras:

:arrow: Não introduzir padrões
:arrow: Fazer a coisa mais simples possivel
:arrow: Refatorar
:arrow: Sem dó
:arrow: Achei algo que parece com um padrão conhecido? Formaliso.

Padrões só devem ser usados inicialmente quando já são a alternativa mais simples; por exemplo, usar FrontController caso o projeto tenha adotado Struts, WebWork ou qualquer outro f/w MVC.

cv:

Quase, Fabio… uma coisa que eu tou vendo todo mundo bater boca nessa thread mas que ate agora nao me convenceram direito eh esse papo de “abstrair o framework”…

Custa TAO caro assim trocar um Hibernate ou Struts por outra coisa, que justifica ficar pensando em esconder o framework como se fosse doenca venerea sem realmente saber se vc vai ter que se livrar dele um dia?

Alguem aqui ja teve que fazer uma migracao dessas, e esconder o Hibernate nos DAOs ajudou alguma coisa, ou soh atrapalhou o progresso te impedindo de usar as APIs mais avancadas como a Criteria, pq ela teria que ser usada em lugares “puros”, e te deixando com o minimo divisor comum da historia?

Concordo plenamente CV, muita gente faz ou ja fez (eu por exemplo) essa de tentar esconder os frameworks usados para quando forem mudar nao ter problemas. Hoje eu tamebm nao penso muito nisso, prefiro usar o que tenho da melhor maneira possivel e simplificar sempre.

]['s

louds:

jprogrammer, eu uso padrões o máximo que posso, mas sempre seguindo as seguintes regras:

:arrow: Não introduzir padrões
:arrow: Fazer a coisa mais simples possivel
:arrow: Refatorar
:arrow: Sem dó
:arrow: Achei algo que parece com um padrão conhecido? Formaliso.

Padrões só devem ser usados inicialmente quando já são a alternativa mais simples; por exemplo, usar FrontController caso o projeto tenha adotado Struts, WebWork ou qualquer outro f/w MVC.

[]'s

Porque não se pode usar o poder dos framworks abstraindo-os ?
Então não posso usar os recursos os SO porque o java abstrai.

É isso que o pessoal fica insistindo.
Tudo fica complicado. Porque ?

Simples é você ter controle em implementalçoes futuras.
Dividindo responsabilidades entre classes e camadas.
Modularizando.

O código fica menor e fica mais simples. Tira acoplamento. Não é só mudança de tecnolgia.

jprogrammer:

Porque não se pode usar o poder dos framworks abstraindo-os ?
Então não posso usar os recursos os SO porque o java abstrai.

Pq a partir do ponto em que voce poe uma cerca em volta dum framework, vc ta impedindo partes do seu codigo de chegar nele, mesmo quando faria sentido que elas o acessassem (criteria e paging do Hibernate no controller web, por exemplo)

Alias, a sua segunda afirmacao responde bem a pergunta: existem dezenas, talvez centenas, de recursos que os sistemas operacionais disponibilizam para as aplicacoes mas que nao estao acessiveis atraves das APIs do Java pq nao sao multiplataforma, exigindo todo tipo de malabarismo com JNI ou COM Wrappers.

E qual o problema de fazer isso através do DAO?O controller solicita ao DAO e ele retorna o que foi solicitado.

Mas é interessante expor o somente o necessário.
ex:

class FuncionarioDAO
{
   public void pesquisar(int codigo, int pagina)
   {
      // chama criteria object
   }

   public void pesquisar(int codigo, string nome, int pagina)
   {
      // chama criteria object
   }
}

Estou expondo o necessario…
ou melhor

class Criterio
{
    public void setPagina(int pagina)
    {
      // chama criteria object

    }

    public void adcionarCriterio(string campo, string valor)
    {
      // chama criteria object

    }
}

class FuncionarioDAO
{
   public void pesquisar(Criaterio criterio)
   {
   }
}

Se um dia eu precisar implementar sei lá uma restrição de consulta por usuário ou um LOG fica mais fácil

E nos casos que tua classe de critério precise suportar uma, ou todas, das seguintes coisas:

:arrow: Preferencias de fetching para otimizar acesso ao banco
:arrow: Ordenação
:arrow: Alias para suportar auto-relacionamentos.
:arrow: Projeção
:arrow: Paginação
:arrow: Locking
:arrow: Caching

Voce vai insistir em implementar tudo isso mesmo que a API de criteria do Hibernate já te forncesse isso?

Você vai criar 1 camada de abstração aos interceptor e event listeners do Hibernate? E acha que um dia vai ser viavel reeescrever os seus DAOs para suportar eles?

Outra coisa, por que existe essa obsessão que código usando frameworks são inerentemente mais desorganizados, dificeis de manter e caóticos em geral???

jprogrammer:

Lógico que custa caro.

Ah é? Como você vai conseguir prever que seu sistema vai precisar deste tipo de característica? Você pode estar antecipando a solução de um problema que nunca existirá e, adivinhe, você perdeu tempo (logo dinheiro) implementando coisas inúteis
E seu cliente vai pagar por isso. E ele vão vai ficar muito feliz com isso.

E ai JProgrammer, blz???

Isso não é bém verdade!!! Se você quiser um maior controle de implementações futuras, vc não vai simplificar seu código, e sim complicá-lo! Você ao invés de se concentrar no problema vai ter que ficar dando uma de
Mãe Diná!!, pois vai gastar tempo prevendo o que irá acontecer e que na realidade ainda nem aconteceu!

Repare que hoje, pelo menos 90% dos programadores pensam que o ideal é programar se preparando para as mudanças. Repare que hoje, o coisa mais nomal dentro do desenvolvimento de software é entregar o Software
atrasado!!!

Eu acho que pattern devem ser aplicados no momento em que se você usando ele haja simplificação considerando o tamanho do problema! Por exemplo, quando você tem pelo menos um 88 Enterprise Beans, será uma boa faze um Service Locator, ou mesmo usar IoC! Mas se vc tiver 4 Enterprise Beans e 2 clientes, será que vc realmente precisa disso?

Olha, se você está realmente afim de fazer uma sistema flexível à mudanças, eu garanto que não é patterns nem implementações escova bits que resolverá seu problema… a solução para desenvolvimento ágil e flexível em mudanças bruscas é essa!

:arrow: Crie bons testes unitários das suas classes negócios!
:arrow: Crie testes para Integração!
:arrow: Testes Unitários devem ser executados várias vezes no mesmo dia durante o desenvolvimento
:arrow: Escreva códigos simples, fácil de entender!
:arrow: Use nome de métodos que facilitem o entendimento de seu funcionamento!
:arrow: Se seu método tiver mais de 20 linhas, quer dizer que ele deve ser quebrado em mais métodos!

:idea: :idea: Seguindo tudo isso, e outras coisas que a gente vai aprendendo com livros e dia a dia de trabalho, o seu código ficará flexível a mudanças. Pois o código é fácil de entender!!

:idea: :idea: Com os testes unitários e testes de integração, você poderá refatorar o seu código à vontade! Pois caso você ou um parceiro introduza um erro, o teste acusará e vocês serão obrigados a concertar!

:arrow: Além de tudo isso dar suporte para que você realize as alterações, você deverá ser ousado e corajoso para alterar alterar algo que ja está funcionando! Aí entra uma coisa basntante interessante!
Dizem que em time que tá ganhando não se mexe! Será mesmo???

Abraços!!!

Thiago Senna:

Isso não é bém verdade!!! Se você quiser um maior controle de implementações futuras, vc não vai simplificar seu código, e sim complicá-lo! Você ao invés de se concentrar no problema vai ter que ficar dando uma de
Mãe Diná!!, pois vai gastar tempo prevendo o que irá acontecer e que na realidade ainda nem aconteceu!

Desculpa Thiago, mas sou obrigado a discordar. Pra o mim o codigo mais propricio a mudancas é o codigo mais facil de entender. Há uma enorme diferenca entre tentar pensar em todo que poderá ser pedido pelo cliente ou simplemente deixar simples o suficiente para na hora da mudanca qualquer um entenda o que é precisdo ser feito.

Isso até parece Modelo Tradicional x XP, verifica qual o mais facil e preparado para mudancas que entenderá o que quero dizer.

]['s

aff… agora quem tá perdido sou eu!!! :lol: :lol:

Sim concordo!!
Foi isso que eu tentei dizer, mas só que com mais linhas!!! hehe!!

Sim, mas não entedi qual é a opção que você prefere! É adivinhar o que o cliente quer ou simplicar para que qualquer um entenda???

Essa minha colocação foi baseada em XP x Tradicional mesmo… hehehe!!! Mas como assim o mais preparado para mudanças??? Eu minha opinião o mais preparada é sem dúvidas o XP??? Afinal, qual é o seu ponto de vista? Confesso q estou boiando um pouquinho!!!

Abraços!

Olá,

O meu ponto de vista é que o simples é o melhor do que tentar adivinhar tudo antes. Eu posso ter lido na corrida e nao ter entendido direito, mas a impressao que fiquei foi a oposta.

Thiago Senna:

Confesso q estou boiando um pouquinho!!!
Abraços!

Fala Thiago, blz?

Ele quis separar as coisas, entenda:

Um sistema flexível a mudanças NÃO implica em um sistema mãe diná : )

Você pode construir seu sistema de maneira flexível suportando possíveis mudanças, mas isso não quer dizer que você esteja prevendo algo.

Deixe o sistema fracamente acoplado, fortemente coeso e bla bla bla enfim, flexível, pois se por ventura uma mudança futura possa vir a surgir, seu sistema suportará melhor essa mudança do que um que não esteja bem formado e flexível.

Flexibilidade não é vidência

Vi neste e em alguns posts ultimamente muita referência a um “sistema feito de maneira simples”.

O que/como seria essa maneira simples de fazer sistema?

faça sempre o minimo que atenda as necessidades do cliente de forma mais simples possivel.
tenha um codigo bem testado, e integrado constantemente.

com isso, qualquer mudança ou implementação nova, torna-se relativamente tranquila de agregar.

não pense no “se”, ou achando que se tal coisa mudar, seu sistema estara pronto p/ mudanças.

mais de 80% das funcionalidades do word, não são usadas pela maioria dos usuario.vc paga(e caro), por um produto que vai ser sub aproveitado.
se ele fizesse o minimo que atendesse as necessidades reais do usuario, com certeza sairia mais barato.
tudo bem que o objetivo da MS é outro, mas foi so um exemplo.

[]'s

é isso que tentei dize jogbt!!!

Skill, também concordo com seu ponto de vista!
Concordo que flexibilidade não é evidência, e foi isso que citei no post lá em cima!

Foi mau!

O problema aparece exatamente quando se perde tempo tentando prever algo e para isso se toma uma decisão para realizar essa possível mudança em um futuro próximo, sendo que na verdade, essa alteração talvez nunca aconteça!!!

Já quanto a flexibilidade utilizando um bom código orientado a interfaces e testes, com certeza tornará o código flexível e simples, fácil se se fazer alterações!

Fabgp, não se preocupe. Vou ver se no próximos emails tento ser mais direto! Obrigado!

Abraços!

Blz Thiago e jgbt,

Agora outro ponto, vocês estão defendendo as praticas ágeis, certo?

Nesse modelo de trabalho, não há uma pré-arquitetura? um perca de tempo para montar mais ou menos ou com uma porcentagem grande de acerto de como a coisa vai ser?

Ou saem codificando, sem qualquer planejamento e no final seja o que sair desde que funcione?

skill_ufmt:

Blz Thiago e jgbt,

Agora outro ponto, vocês estão defendendo as praticas ágeis, certo?

Nesse modelo de trabalho, não há uma pré-arquitetura? um perca de tempo para montar mais ou menos ou com uma porcentagem grande de acerto de como a coisa vai ser?

Ou saem codificando, sem qualquer planejamento e no final seja o que sair desde que funcione?

sempre ha uma pre-arquitetura e estimado tempo de projeto.
so que isso é uma estimativa, não um tempo exato das coisas.

ninguem sai codifcando, pelo contrario, ha muito planejamento, reuniões diarias da equipe, troca constante de informações, e de know how.

a diferença, é que vai se pensando em pequenos pedaços, que são o cliente que escolhe, e apos esse “pedaço” estar pronto, o cliente escolhe o proximo e assim vai…sempre pensando de maneira simples(exemplo simples).

claro que cada projeto tem suas particularidades, mas se vc trabalhar dessa maneira um dia, vc vera que tem diferenças, p/ melhor.

[]'s

skill_ufmt:

Blz Thiago e jgbt,

Agora outro ponto, vocês estão defendendo as praticas ágeis, certo?

Nesse modelo de trabalho, não há uma pré-arquitetura? um perca de tempo para montar mais ou menos ou com uma porcentagem grande de acerto de como a coisa vai ser?

Ou saem codificando, sem qualquer planejamento e no final seja o que sair desde que funcione?

Kivanio,

Pense um pouquinho. Nos modelos tradicionais de desenvolvimento, onde um bom tempo é perdido pensando o sistema, quantos terminam como comecaram?
Nenhum ou quase nenhum certo? Entao qual a diferenca de sair fazendo ou desenvolver toda uma arquitetura que depois sera perdida ou muito alterada? A perda de tempo certo?
Nao que tu va sair coficando sem pensar, mas se teu sistema estiver quebrado em pequenas funcionalidades a serem implementadas fica mais facil desenvolver e mais facil alterar conforme as necessidades.
Enquanto o projeto existe vai fazendo como ja foi falado aqui, acredito que pelo pcalcado.

while (projetoEmAndamento) { refatora(); codifica(); }

]['s

Estou querendo implantar isso aqui sim

Bom sei que vou por partes e simples era só apra ver qual o conceito que vocês têm de simples.

Você disse, faz-se uma parte e depois a outra conforme o cliente solicita, certo?

Mas como desenvolver essa outra parte se tu nem sabe o que será?
acredito que esteja falando isso referente ao mesmo escopo de projeto, certo?

Mas enfim, planejar sempre é o começo para tudo dar certo, e não venham me dizer que refatorar aquilo que nem estruturei ainda é melhor heheh

fabgp2001:

while (projetoEmAndamento) { refatora(); codifica(); }

]['s

foi o Shoes sim

Pois é, é que eu disse, desenvolver em releases.
Mas mesmo assim acredito que um planejamentozinho é necessário, sair criando coisa em cima de coisa sem ter nem o minimo de estrutura na mente, acho que é suicídio, ou isso dá certo? Você já fez um sistema onde não planejou nada?

De acordo com todo o resto do post do Fabio, mas tem uma omissao gigantesca na brincadeira toda. Consertando:

while (projetoEmAndamento) { testa(); defineProximasTarefas(); codifica(); refatora(); testa(); }

Claro… planejamento é necessário1

Por isso no XP todo dia deve acontecer o Stand Up Meeting, que é uma breve reunião onde acontece sobre o que será feito naquele dia!

Toda semana deve ser feita uma reunião para fazer e rever o planejamento… ou algo do tipo… hehe!!!

Outro fator importante no caso do XP é que o cliente deve estar sempre presente, ou pelo menos, muitíssimo frequente!

skill_ufmt:

fabgp2001:

while (projetoEmAndamento) { refatora(); codifica(); }

]['s

foi o Shoes sim

Pois é, é que eu disse, desenvolver em releases.
Mas mesmo assim acredito que um planejamentozinho é necessário, sair criando coisa em cima de coisa sem ter nem o minimo de estrutura na mente, acho que é suicídio, ou isso dá certo? Você já fez um sistema onde não planejou nada?

acho que vc ta confundindo fazer as coisas de maneira simples, com não ter planejamento.
como eu disse, existe sim, e muito planejamento, so que o que importa mais são as iterações(releases), o planejamento é focado nisso, no que esta sendo implementado, e não no sistema em um todo.

[]'s

cv:

De acordo com todo o resto do post do Fabio, mas tem uma omissao gigantesca na brincadeira toda. Consertando:

while (projetoEmAndamento) { testa(); defineProximasTarefas(); codifica(); refatora(); testa(); }

Gostei do Refactoring :D.
Só me diz uma coisa CV, esta é a ordem que tu prefere??

codifica(); refatora();

ou seria algo assim:

refatora(); codifica(); refatora();

Pergunto isso, porque é normal o cara fazer um refactoring antes de sair mexendo, claro se isso for necessário.

]['s

O que acham do Power Design-pattern KISS?
(Keep It Simple Stupid!)? :mrgreen:

Esclarecendo…

è necessário planejamento sim, e focado sim nos releases.

Não to confundindo com o processo todo, só estava abstraindo a coisa por demais ehhe

Só queria mesmo dizer quer deve-se planejar ou falhará, e que estes planejamentos sejam o menores possíveis ou seja, por releases, e que isso deve ser entregue ao cliente depois de testado e tudo mais.

isso mesmo, planejamento é importante em qualquer coisa que vc for fazer, não so em sistemas.

so que palnejar coisas pequenas(releases) é mais facil do que coisas grandes(projeto).

planeje o projeto, mas apenas para ter uma referencia, foque no planejamento das tarefas, e se esse palnejamento exigir, mude sua referencia.

[]'s

Abstraindo partes do framework não quer dizer que voce irá esconde-lo.

criando por ex uma classe Criterio você pode ir adicionando os recursos da classe Criteria que for utilizando e ainda utiliza tudo isso que você falou.
Você não precisa adivinhar tudo.

O segredo é separar as responsabilidades para ir implementando. É lógico que sempre é mais dificil na primeira vez, mas depois colhera os beneficios.

Enquanto os interceptors não precisa ser abstraido pois é parte da implementação e não da interface. o que importa que nas classes de negocio que contém o código pesado você abstrai a implementação.

E pra que voce vai enfiar uma classe Criterio, que nao faz parte do seu modelo de negocio, so pra abstrair o framework? Eh trabalho inutil, jprogrammer. A primeira coisa que qualquer um olhando um codigo desse vai fazer ao ter que dar manutencao vai ser arrancar essa classe dai e expor o Hibernate, pra poder entender o que esta acontecendo direito. Entao, pra que colocar ela la? :?

Para mim expor o framework é mesma coisa que colocar a select no meio do código.
Agora me fale que por acaso você também coloca aquele HQL no meio da camada de negócio ?
Aí eu desisto !!!

Rapazes, que tal um suco de NONI para refrescar? :mrgreen:

Onde voce poe?

dentro do DAO

O que eu insisto: A camada de negócio deve ver apenas a interface
ex:

class NotasFiscaisDao
{
    public void darBaixa(int mes)
    {
        String hql = "update .....";
       // faz o resto;
    } 
}

class NotasFiscais
{
    public void darBaixaMes()
    {
       NotasFiscaisDao.darBaixa(Meses.JANEIRO);
    }
}

Onde voce poe? ;)

Dentro dos XML do Hibernate. :mrgreen:

Taí uma solução interessante…

Olá

jgbt:

faça sempre o minimo que atenda as necessidades do cliente de forma mais simples possivel.
tenha um codigo bem testado, e integrado constantemente.

com isso, qualquer mudança ou implementação nova, torna-se relativamente tranquila de agregar.

não pense no “se”, ou achando que se tal coisa mudar, seu sistema estara pronto p/ mudanças.

mais de 80% das funcionalidades do word, não são usadas pela maioria dos usuario.vc paga(e caro), por um produto que vai ser sub aproveitado.
se ele fizesse o minimo que atendesse as necessidades reais do usuario, com certeza sairia mais barato.
tudo bem que o objetivo da MS é outro, mas foi so um exemplo.

Neste tópico li algumas coisas que não concordei mas esta mensagem realmente merece 5 estrelas.

[]s
Luca

Alguma coisa com o que vc nao concordou em especifico, Luca? Poe mais lenha na fogueira

E olha que para o Luca colocar lenha na fogueira não é difícil!

É só ele não colocar o Olá no início da mensagem dele que logo será motivo para percebermos que alguma coisa está errada! Vou tirar 4 estrelas no Luca por que ele não colocou lenha na fogueira!!!
:lol: :lol: , brincadeira!!!

abraços!

Muita gente confunde simples com simplório.
Concordo que temos que fazer o estritamente necessario, mas de uma forma organizada.
Ninguem tem bola de cristal para adivinhar o que poderá acontecer, mas separar resposabilidades no sistema, auxilia na manutenção e simplifica.
Esse negócio de camadas e patterns não foi feito de bobeira…

Ter estrutura elaborada não quer dizer funcionalidades extras…

jprogrammer:

Muita gente confunde simples com simplório.
Concordo que temos que fazer o estritamente necessario, mas de uma forma organizada.

Tá ai…
É muito mais fácil organizar o que é simples!!! Por isso devemos nos preocupar apenas com o que é necessário!!

Ola

(sem acentos pois acabei de trocar o teclado)

Este topico foi otimo. Muita coisa inteligente foi dita. Acredito que o jprogrammer tenha aproveitado bastante. Vamos ao que discordo e que jah foi por demais debatido (muito bem por sinal)

1. Com a insistencia em abstrair o framework (mas no exemplo apareceu HQL no DAO). Nao vejo nenhuma vantagem nisto ate porque eh dificil trocar de framework.

2. Com a insistencia em reinventar a roda (soh vale se for para aprender). Eu jah desenvolvi muitas bibliotecas mas foi no tempo em que nao havia solucoes prontas free.

[]s
Luca