Iniciando um projeto WEB!

jmedeiros:

Pessoal,

Estou iniciando no desenvolvimento web e estou querendo usar apenas JSP e Servlet(como já me indicaram aqui no forum) , tenho uma aplicação utilizando fachada que segue essa estrutura.

Camada de Dados -> Camada de Negócio -> Camada Fachada

Onde minha fachada possui todos os metodos que eu preciso, a pergunta é que quando eu usava este sistema em desktop(swing) eu capturava os campos com campo.getText() por exemplo.

Eu poderia fazer isso com uma aplicação WEB utilizando JSP?

Como eu poderia proceder nessa situação? :?

Muda só um pouquinho para:

<%=request.getParameter(“nomeDoParametro”)%> Na view ou servlet

e para setar algo:

<%=request.setParameter(“valorQueQuerPassar”,“nomeDoParametro”)%> Na view ou servlet

Mas então eu teria que transforma minha fachada em uma servlet? pra receber os parametros. :?:

jmedeiros:

Mas então eu teria que transforma minha fachada em uma servlet? pra receber os parametros. :?:

Acredito que sua fachada seja o pattern Facade, certo?

Em sendo, você está com varios métodos nela ou apenas chamando ou método operações a banco de dados, ou qualquer itpo de método, certo?

Em suma, estes métodos retornam um objeto ou uma lista de objetos, certo?

Se tu ta fazendo algo para web, ta usando sevlet, ou não?

Se tu está usando servlet, você simplesmente pode importar usa fachadada, chamar seus métodos da sua fachada, pegar o resultado do método e atribuir ele a variáveis que você usará no JSP.

Exemplo:

//Este método retorna uma pessoa com nome e idade
Pessoa novaPessoa = buscarPessoa();
//pega o nome da pessoa que sua fachada retornou e seta em uma váriavel para utilizar na view
resquest.setParameter("novaPessoa.getNome()", "nomePessoaNaJsp");
//pega a idade da pessoa que sua fachada retornou e seta em uma váriavel para utilizar na view
resquest.setParameter("novaPessoa.getIdade()", "idadePessoaNaJsp");

Lá ná JSP:

Voce pode pegar essas variáveis:
.
resquest.getParameter("nomePessoaNaJsp");
resquest.getParameter("idadePessoaNaJsp");

E o processo inverso é o mesmo princípio, só que não precisa setar nada na JSP, o “request” pega os valores que estão nos seus “imput” do form do seu html.

Digamos que você tenha:

<INPUT name=“nomePessoa”
value=“José”>

no seu servlet você deverá buscar o nome do input:

resquest.getParameter(“nomePessoa”);

O exemplo é bem banal, mas espero que te ajude de alguma forma, no mais estamos por aqui

Medeiros… posso colocar uma pulga atrás da sua orelha???

Dependendo do seu projeto, é melhor você usar uma estratégio Command and Controller!!!

Façade é ideal para aplicações distribuiídas, mas para rodar no mesma jvm é só adição de complexidade.

Digo isso por que comecei meu projeto usando façade… e mudei para a estratégia Command and Controller…!!!

Abraços!

jmedeiros, usando estas duas tecnologias sempre há uma forte dependência entre a página html/jsp e o servet. As sugestões do skill_ufmt são ótimas para este começo.

Mais para frente vale a pena procurar pelos tópicos indicados pelo Thiago.

Valeu galera pelas dicas!

Realmente esclareceu muitas dúvidas! mas ainda tenho que estudar muita coisa!

Valeu mesmo!

setParameter?

Bom,

Pelo que entendi ele necessitava do básico de imediato, não quis lhe passar mais informações para não confundi-lo.

É claro que FrontController, Filter e bla´bla, JSTL, são necessários, mas com o tempo ele vai descobrindo isso.

Thiago, não entendi o porque de não usar Facade? qual a complexidade?
Se não esta usando Facade, como esta isolando seus DAOs, por exemplo do resto dos servlets?

Uso Facade perfeitamente neste modelo e acho que agrega muito valor, consigo isolar completamente minha aplicação dos métodos de banco, usando intermediários como Entyte, Helper e uma Factory de DAOs.

Guilherme Silveira:

skill_ufmt:

<%=request.getParameter(“nomeDoParametro”)%> Na view ou servlet

e para setar algo:

<%=request.setParameter(“valorQueQuerPassar”,“nomeDoParametro”)%> Na view ou servlet

setParameter?

ops

ctrl + c ctrl + v

é foda ; )

request.setAttribute(“valorQueQuerPassar”,“nomeDoParametro”);

certo Silveira?

skill_ufmt:

ops

ctrl + c ctrl + v

é foda ; )

request.setAttribute(“valorQueQuerPassar”,“nomeDoParametro”);

certo Silveira?

Foi so para brincar mesmo. Erro comum quando a gente faz de cabeca. Quantas vezes ja nao fiquei quebrando a cabeca:

Pq esse setParameter nao esta funcionando? Eu SEMPRE fiz ele assim Ai depois d emeia hora percebe que escreveu parameter

Abraco

Guilherme

Guilherme Silveira:

skill_ufmt:

ops

ctrl + c ctrl + v

é foda ; )

request.setAttribute(“valorQueQuerPassar”,“nomeDoParametro”);

certo Silveira?

Foi so para brincar mesmo. Erro comum quando a gente faz de cabeca. Quantas vezes ja nao fiquei quebrando a cabeca:

Pq esse setParameter nao esta funcionando? Eu SEMPRE fiz ele assim Ai depois d emeia hora percebe que escreveu parameter

Abraco

Guilherme

e como da uma dor de cabeça hehehe

E ai Skill… tudo bém???
Quanto tempo hein??

Por favor, alguém me corrija se eu estiver errado. O Façade em uma arquitetura que esteja na mesma jvm e numa aplicação web que tenha a arquitetura MVC em minha opinião aumenta um pouco a complexidade. Digo isso porque as Actions ou os Commands desempenham o papel das Fachadas… ou seja… ele iniciará uma transação, conterá a s lógicas de negócio, chamará os Daos para persistência e etc…

Então eu pergunto. O que é que um Façade faz??? Faz o que citei acima, e te tá uma objeto que contém todas as operações que o sistema pode realizar. Supondo que você tem um Action, a única coisa que o action irá fazer é chamar o façade! Isso nada mais é do que um Overload de patterns! Outro detalhe é que no caso dos commands é mais fácil integrar com um FrontController, já no façade isso é possível, mas um pouco mais difícil. Pelo menos eu acho!!!

Já numa aplicação distribuída, considerand que você colocou em um façade todas as operações que o sistema poderá realizar, então isso fará com que um outro programador que está desenvolvendo a camada cliente sinta-se mais a vontade de delegar tarefas para a camada de negócios!

Eu entendo o façade como uma maneira de você separar a camada de negócio da camada cliente (ou controle). Ele só será realmente útil em um caso onde você quer proteger sua lógica de negócio de qualquer barbeirisse dos desenvolvedores que trabalham na camada controle! Não estou criticando a arquitetura, mas sim que é possível se fazer o mesmo com menos!!!

Abraços
Thiago

Simples… Será que você realmente precisa fazer esse isolamento? Será que uma fábrica de DAO já não seria suficiente???

Você tem certeza que futuramente esse isolamente que você pode fazer com façade será realmente útil?

Você acha que essa camada de persistência isolada será realmente um dia reutilizado???

Abraços!!

Tempo, paro o projeot lá? : )

Bom, Facade pra mim é tudo que se possa ser fachada : )
Não somente negócios/cliente, voce pode ter negocio/banco usando facade.

A Facade é usada sempre que você precise isolar algo, ou seja, encapsular.

no teu caso, tu usa uma facade pra encapsular como o cliente vai ver seus negócios, no meu caso, somente para que os negócios não vejam os DAOs.

Só são locais diferentes, mas o mesmo prícinpio.

No teu caso eu concordo que commands é melhor, até por ser um padrão para isso, no caso SUN. e até mesmo uns filters e etc.

Considerando meu suo, pode ser que realmente minha fabrica nunca mude, mas não acredito nisso, ja ouviu a frase “os requisitos sempre mudam” pois é, ta ai o problema hehe

Se um dia eles mudarem, meus clientes/negocios não vão nem querer saber disso e nem precisaram, pois somente atualizaria minha factory
E minha facade continuaria intacta, isso considerando uma atualização, não novas funcionalidades, pois ai teria que alterar também a Facade.

Não se entendi bem o que tu disse, mas disse que sua Facade tem lógicas de negócios? e por isso usa commands?

Acredito que facade nunca deve conter lógica alguma a não ser chamadas á métodos de outros, caso contrário não seria uma facade.

Abraços

PS: desanima com o proejto não que logo to efetivamente lá

Quanto ao projeto… parou não cara… só tá embaçado de separar tempo para dedicar nele… mas o projeto vai pra frente sim!!!

Sim, os requisitos mudam. Para é melhor esperar eles mudarem. Caso isso aconteça, faça um refactoring e adicione os Façades. Imagine se por acaso você faz uma arquitetura super reaproveitável, e para seu asar os requisitos nunca mudam… e se mudam, mudam pequenos detalhes!!! É um esforço em vão, é isso que eu quis dizer!

Hehe… me expressei mau!!! Concordo com vocÊ… não deve ter logica de negócio…

Abraços!

Este também é meu problema, pelo menso neste mês, depois vamo entrar de cabeça no projeto

Considerando que detalhes como você disse, também são mudanças e que afetam sim alguma coisa, caso contrario não seria uma melhora, certo?

Alguma vez na sua vida, por favor me diga, algum raio de requisito seu NUNCA mudou?

Se não mudou meu hiper extensivos parabéns, pois tu é o cara

Hehe… me expressei mau!!! Concordo com vocÊ… não deve ter logica de negócio…

Abraços!

Aeeeeeeeee d: )

Abraços

Claro que sim… é innevitável! O problema é que a gente nunca sabe onde o requisito vai mudar! O pior é que requisito vai mudar bém naquele ponto onde você não se preveniu!
Por isso é melhor você adotar refactoring do que tentar ficar prevendo mudanças!

É, então eu não sou o cara!

Thiago Senna:

Claro que sim… é innevitável! O problema é que a gente nunca sabe onde o requisito vai mudar! O pior é que requisito vai mudar bém naquele ponto onde você não se preveniu!
Por isso é melhor você adotar refactoring do que tentar ficar prevendo mudanças!

É, então eu não sou o cara!

Então não preveu as mudanças direito ehehe

Eu acho que o cara bom realmente em arquitetura, analise, é aquele que consegue prever 99% do que poderá mudar.

Refactoring é massa, mas é tempo disperdiçado, é conserto, e tal, é o último caso a ser usado pelo menos para mim.

3 regras da OO:

Programe para interface.
Prefira delegação.
ENCAPSULE tudo que possa ser variável.

Se não obdecer as regras, nãos estais programando OO direito.

O que é o meu caso ehehe to longe de chegar a saber OO pura, será que o Martin Fowler, sabe? ele deve saber, ele é o cara hehehe.

Outro dia vi o Shoes falando que conhece 4 caras que sabem OO de verdade, eu não conheço nenhum, mas gostaria de conhecer e trocar uma idéia.

Ae Shoes apresenta pra nós d: )

skill_ufmt:

Outro dia vi o Shoes falando que conhece 4 caras que sabem OO de verdade, eu não conheço nenhum, mas gostaria de conhecer e trocar uma idéia.

Acho que foi o LIPE que falou isso.

[]'s

caiofilipini:

skill_ufmt:

Outro dia vi o Shoes falando que conhece 4 caras que sabem OO de verdade, eu não conheço nenhum, mas gostaria de conhecer e trocar uma idéia.

Acho que foi o LIPE que falou isso.

[]'s

Ah hehe
ratificação então, o LIPE falou que conhecia 4 caras…

De qualquer forma.

Apresenta pra nós ae LIPE : )

Ai!!! Como é que um cara realmente bom vai conseguir prefer 99% das mudanças:??? Desde quando o cliente é um cara previsível??? Nem Erici Gama mas os outros três carinhas lá que escreveu o livro com ele conseguiriam esta proesa!!!

Cara… isso é pior que um palavrão!
Quando você aplica um refactoring, você está mudando algo que realmente é necessário, e que realmente vai mudar com frequência.

Perder tempo é ficar achando que patterns vai deixar seu sistema completamente ileso à qualquer mudança! Vou enumerar os porques!!!

1 - Você deverá prever tudo que poderá acontecer!
2 - Um previsão vai levar você a outra previsão, que leva a outra, e outra, e outra…
3 - Você deverá aplicar patterns, por isso deverá definir bém quais patterns usar!
4 - Você deverá conhecer todos os patterns que serão utilizados, então terá que aprender!
5 - Quando se coloca um pattern no projeto, vc adiciona complexidade e burocracia no seu código. Então uma alteração que afetaria 2 classes afetará agora pelo menos 4 classes ou mais!
6 - Para adicionar um novo profissional para ajudá-lo, ele deverá conhecer patterns, logo, é um profissional mais caro!
7 - Fazer qualquer diagrama usando UML será uma aventura!
…
…
…
E para finalizar:

Mais de 90% do que você previu que seria alterado nunca será realmente alterado!

OU seja, só 10% do seu esforço realmente valeu a pena, e os outros 90% poderia ser usados para garantir que o sistema fosse entregue no prazo e poderia ser usado aplicando refactorings quando necessário!

3 regras da OO:

Programe para interface.
Prefira delegação.
ENCAPSULE tudo que possa ser variável.

Se não obdecer as regras, nãos estais programando OO direito.

Bom, recentemente tivemos uma discussão feia aqui no GUJ sobre isso… aquele tópico que começou falando de delphi e depois mudou para java beans, maldição ou salvação!.. lembra???

A conclusão que cheguei de tudo aquilo é que quanto mais patterns vc colocar no seu projeto, mais estruturado seu projeto fica, e menos OO!!!

O que você postou e que eu demarquei em cima está correto, mas não condiz com o que você defendeu até aqui, que é a utilização de patterns para deixar seu projeto flexível no caso de mudanças!!!

Só isso… hehe
Abraços!

Pena que um cara bom desse nao existe (ja que vc mencionou o Martin Fowler, eu por acaso trabalho com ele - e posso dizer com toda certeza que ele discorda veementemente da sua opiniao, preferindo refactorings e design evolutivo).

Tempo desperdicado eh bolar o sistema antes de comecar, jogar tudo fora e fazer de novo a cada dois meses. Ou entao ter aquele momento “xi, e agora marquinho?” e arregacar a arquitetura do sistema jogando OO, bons principios da programacao, patterns, prazos, o namoro e se deixar ate a mae do cliente pela janela.

Ja que voce concorda em pelo menos um ponto comigo, de que o Martin Fowler eh o cara, vale a pena dar uma lida no site dele, http://www.martinfowler.com - coisa que, pelo seu post, nota-se que voce nao fez.

Bom, aqui você cita:

Tudo isso é trabalho pra quem? Desenvolvedor ou Arquiteto?
Minha resposta é Arquiteto.

Se é Arquiteto, é de pensar que obrigatoriamente ele deveria fazer o que você citou ai em cima, ou não?

E se ele tem que fzer, que faça bem feito, concorda?

Quanto ao preço do profissional, você quer um cara que faça tudo isso ae
pra pagar uma mer… de salário para ele?
Ai vamos cair na discussão a desvalorização do conhecimento,
que não é o foco agora

Eu pagaria par aum cara que sabe tudo isso ae muito bem sim,
até porque não vou precisar de 20 caras desse ai na minha equipe,
um apenas bastaria, certo?
E ele é arquiteto e vai ta la para isso, desenvolvedor vai ta la pra ver o
que ele quer e fazer, todo desenvolvedor que se preze tem de saber pelo
menos o basicão de patterns, pelo meos pra ler algo do tipo,
se não é uma merda só depois e ai vem os seus queridos refactoring
para refazer tudo e deixar legalzinho.

Não to dizendo que refactoring é ruim, é bom claro, mas deve-se evitá-lo.
Se vai fazer alguma coisa que faça direito, não faça do jeito que precise
ficar refazendo. é logico isso, é melhor fazer algo 1 vez ou 3, 4?

Acho que você está aderindo a idéia de que Analisar o problema antes de fazer é solução ruim.
Mas os fatos e pesquisas mostram que somente quando gastasse tempo
com analise, arquitetura e bla blas, é que você tem sucesso no seu projeto.

Sair fazendo as coisas sem saber onde vai pisar mais tarde é burrice, concorda?

Nunca estaremos livres de refactoring, mas podemos diminuir ele ao extremo sim.

3 regras da OO:

Programe para interface.
Prefira delegação.
ENCAPSULE tudo que possa ser variável.

Se não obdecer as regras, nãos estais programando OO direito.

Bom, recentemente tivemos uma discussão feia aqui no GUJ sobre isso… aquele tópico que começou falando de delphi e depois mudou para java beans, maldição ou salvação!.. lembra???

Lembro.

Acho que você está confundindo os dois paradigmas.
Padrões são aperfeiçoamentos no uso de OO, ou melhor, é como se deveria usar OO.

Os dois não adam separados de forma alguma.

Mas não mudei meu foco hehe
Realmente to te dizendo que os padrões,
servem a esse propósito primordialmente, e a uma série de outros em seguida.

E antes que alguém poste, é claro que padrões também têm suas desvantagens.

Abraços.

:!: design vident detected :!:

Parem de confundir a cabeça do cara que tá començando :hunf: não adianta porcaria nenhuma se enfiar num livro de patterns para j2ee sem saber o básico de j2ee. Tem que sofrer um pouco, ver que é uma merda abrir connection no servlet, que é uma desgraça colocar query string no meio do código, etc.
Quando ele perceber que está tendo trabalho demais, quer dizer que entendeu um pouco como a coisa funciona, e só então será útil estudar melhores formas de resolver os mesmo problemas.

Apressadinhos :XD:

Po, show, tem vaginha ae não?

Olha, vamos esclarecer heehe

Não sou a favor de prever 99%, como você mensionou, é impossível.
Mas também não sou a favor de 99% de Refactoring

Quanto aos artigos do martin, tenho lido alguns sim, apenas não cheguei a conclusão ainda de qual é a opinião formada dele hehe talvez por não ter lido todos ainda e nem o tão sonhado Refactoring dele que pretendo ler no próximo mês.

Mas ando lendo muita coisa sobre padrões e OO(Monografia sabe como é né ) para defender a monografia na próxima segunda, 28.
Estou apenas treinando meus argumentos e confrontando idéias que se parecem sólidas

Você disse que o Martin é a favor de refactoring, certo? mas até a que nível? refatorar tudo? 10%, 50%?

Estive vendo sobre IOC num artigo que é dele se não me engano, aquilo para mim aparentemente é OO pura, muita interface e tal.
Agora aquilo também é um padrão, certo?

Bom, já que tu é o cara e amigo do cara, poderia me dizer a opinião dele ou a sua, de como seria esse relacionamento entre Flexibilidade com padrões e optar por fazer merda ou quase merda e usar refactoring depois?

Estou partindo do principio onde estamos na primeira versão de um software sem finalização, não onde precisamos refatorar para usrgir uma segunda versão, ok?

Abraços.

LIPE:

Parem de confundir a cabeça do cara que tá començando :hunf: não adianta porcaria nenhuma se enfiar num livro de patterns para j2ee sem saber o básico de j2ee. Tem que sofrer um pouco, ver que é uma merda abrir connection no servlet, que é uma desgraça colocar query string no meio do código, etc.
Quando ele perceber que está tendo trabalho demais, quer dizer que entendeu um pouco como a coisa funciona, e só então será útil estudar melhores formas de resolver os mesmo problemas.

Apressadinhos :XD:

hehehe

Eu tentei dizer isso no meu segundo post mas a discussão se esquento heehhe

Vamos mudar de post então? abrir outro? um antigo?

Skill:

Acho que você está aderindo a idéia de que Analisar o problema antes de fazer é solução ruim.
Mas os fatos e pesquisas mostram que somente quando gastasse tempo
com analise, arquitetura e bla blas, é que você tem sucesso no seu projeto.

Sim, desde que você more lá na ìndia, onde a mão de Obra é Barata!!!
Afinal, no caso de uma alteração, você precisará de um analista, de um arquiteto e de um desenvolvedor para manter as documentações referente a análise e arquitetura atualizados com relação ao código nos casos de alterações!!!

Sim, podemos.
É só você fazer um contrato fechado com o cliente, onde uma vez que ele faça os requisitos, espere o sistema chegar pronto na mão dele. Evitar o máximo possível de Feedbak do cliente seria melhor ainda.
Evite reuniões com o cliente. Não deixe ele dar opinião sobre o sistema.
Não deixe o cliente testar o sistema antes dele ficar pronto! Caso ele ache que algo tenha que mudar, diga que precisará fazer um orçamento… daí, vc deverá meter a faca no orçamento. Assim ele desiste da mudança, e assim não haverá refactoring!!!

Que tal matarmos ele? seria mais fácil

Não Skill, isso também naum…
Se esse cliente morrer, vão colocar outro no lugar dele! Ai esse novo cliente pode acabar querendo mudar tudo que já tinha sido definido!

Isso só vai dar dor de cabeça!

Voces (Thiago e Kiviano) estao confundindo refactoring com retrabalho. Refactoring eh SEMPRE positivo, e deve ser encorajado no desenvolvimento de software, por melhorar a qualidade e coesao do design.

Retrabalho eh, geralmente, negativo. Logo, deve ser evitado a menos que sua necessidade seja maior do que a perda de tempo que ele causa.

A definicao de refactoring, que voces provavelmente nao leram, do site www.refactoring.com:

CV,

Mas é justamente isso que to tentando defender, que refatoração, não é fazer novamente, e sim “ajustar” o que ja está feito, sem grandes mudanças, e contanto que elas não interfiram no fluxo da aplicação.

Defendo que gaste-se tempo para fazer uma arquitetura confiável e com as boas práticas de OO e padrões, e que feito isso, como tudo é mutável, ajustamos através de refatoração, mas sem mudar o cerne da arquitetura com padrões.

Mas não que se use refatoração como meio de arrumar tudo. mudar estruturas e etc.

Não Skill, isso também naum…
Se esse cliente morrer, vão colocar outro no lugar dele! Ai esse novo cliente pode acabar querendo mudar tudo que já tinha sido definido!

Isso só vai dar dor de cabeça!

Malditos clientes hehehe

A nanotecnologia ou a IA podiam no futuro atuar em softwares fazendo com que esles se auto refatorem

Seria tão bom…

Leia o paragrafo que eu quotei de novo: refactoring eh exatamente mudar o fluxo da aplicacao sem mudar o comportamento externo! E ainda por cima eh a parte que eu negritei, diacho :evil:

E o que te leva a crer que mesmo tudo sendo mutável, “o cerne da arquitetura” tem que permanecer o mesmo?

kkk CV nervoso na área,

Talvez me espressie com as palavras erradas, mas eu queria dizer isso,
que no refatorar eu por exemplo mudaria a lógica de como busco o nome
de uma pessoa no módulo pessoa, mas o cliente que sempre requisita
essa consulta nem saberá que você mudou, pois esta mudança não implica
mudanças nele, que no caso é o externo ao modulo Pessoa.

E o que te leva a crer que mesmo tudo sendo mutável, “o cerne da
arquitetura” tem que permanecer o mesmo?

Se eu mudar o cerne da arquitura não estaria fazendo outra arquitetura?
isso não seria retrabalho?
não seria minha a culpa de não ter entendido ou adquirido os requisistos corretamente?
Isso ainda estaria encaixado num escopo de refatoração?
ou seria uma mudança geral?

isso sem considerar mudanças por parte do cliente que resolve que quer
tudo diferente.

Nao - enquanto o comportamento externo do metodo/classe/pacote/modulo/sistema for o mesmo, ainda eh refactoring.

Se voce quiser apontar um culpado, fique a vontade - eu aposto que voce e o seu cliente estao mais interessados em ver software funcionando e mais dinheiro no bolso de todo mundo. Mas, de qualquer forma, interessante a sua opiniao sobre o comportamento dos clientes. Como sugestao, leia isso: http://c2.com/cgi/wiki?EmbraceChange

Então quando mudo isso metodo/classe/pacote/modulo/sistema tenho meu cerne mudado e chegamos onde eu queria eheh

Bom, valeu pelas discussões, tenho certeza que incrementou bastante meus poderes defesa e meus poucos conhecimentos.

Como disse no começo estava apenas confrontando idéias, mas sou adepto das Metodologias Ágeis(XP, Scrum) e com foco extremo na minha equipe e não em papeladas.

Refactoring é sempre bom e necessário, desde que seja um refactoring e não uma mudança de cerne.

talvez os padrões possam endurecer o processo ágil, mas o processo ágeil também necessita de seus padrões.

Enfim, viva o refactoring, os padrões e as metodologias ágeis

Abraços.

só pra constar CV, o link não ta funcionado

É valeu pela discussão!

Como sempre, somo ótimos em mudar o assunto de um tópico… hehehe!!!

Skill, quando o bicho pegar no JRapido a gente vai ter oportunidade de discutir o assunto de novo e na prática!!! HEHEHEHE!!!

Que o XP, Refactoring e padrões de projeto bém empregados vivam felizes para sempre!

Até o próximo capítulo!!!

Thiago Senna:

É valeu pela discussão!

Como sempre, somo ótimos em mudar o assunto de um tópico… hehehe!!!

Skill, quando o bicho pegar no JRapido a gente vai ter oportunidade de discutir o assunto de novo e na prática!!! HEHEHEHE!!!

Que o XP, Refactoring e padrões de projeto bém empregados vivam felizes para sempre!

Até o próximo capítulo!!!

conxerveja, e vamos a la prática.