Bom dia pessoal. Estou desenvolvendo um projeto concreto em Java utilizando eclipse e fico muito confuso por ser iniciante sobre os tais padrões de projeto. Já ouvi falar do DAO que serve para manipulação dos dados do objeto, do MVC, que separa as camadas de modelos de objeto, visualização, e controle, contudo, não sei organizar meu projeto direito ainda. Eu já tenho conhecimento de OO, o próximo passo mais importante seria aprender melhor essas técnicas ou tem outra coisa que eu tenha que entender para me firmar mais na programação em Java?
[quote=juninhodg]Bom dia pessoal. Estou desenvolvendo um projeto concreto em Java utilizando eclipse e fico muito confuso por ser iniciante sobre os tais padrões de projeto. Já ouvi falar do DAO que serve para manipulação dos dados do objeto, do MVC, que separa as camadas de modelos de objeto, visualização, e controle, contudo, não sei organizar meu projeto direito ainda. Eu já tenho conhecimento de OO, o próximo passo mais importante seria aprender melhor essas técnicas ou tem outra coisa que eu tenha que entender para me firmar mais na programação em Java?
Abraços.[/quote]
Conhecendo a sintaxe do Java e experiência com desenvolvimento OO, já tem um ponto positivo e importante.
Aprender, sempre temos. Você exerce a profissão a anos e sempre precisa manter-se atualizado, isso é inevitável. Sobre o que aprender, vai um pouco do nicho que você deseja atuar. Tentar aprender JEE e AWT ao mesmo tempo, pode ser um problema, por exemplo.
Sobre os padrões de projetos, são inúmeros. Mas eu diria que ter em mente MVC (senão me engano, tem um conceito mais atualizado), OO e “desenvolvimento orientado a interfaces” é fundamental para iniciar qualquer projeto. Você já tem uma área de atuação que deseja seguir ?
fala nel. Cara eu já atuo como programador Delphi - Firebird - MySQL em sistemas de automação comercial e soluções para empresas como controle de frotas de veículos. Só que eu ando visando há algum tempo “migrar” pra Java, pela flexibilidade da linguagem ser incomparavelmente maior. Não pretendo sair dessa área por enquanto, e se for sair, me aprofundar bastante nos conceitos mais importantes antes de fazê-lo.
Não é a isso que eu me refiro.
Você tem interesse em Java e quer seguir a área, ok. Comece pelo básico, procure apostilas (Caelum tem ótimas apostilas) para estudar o básico, ver bem OO, as classes “básicas”, como Collection, Maps, Wrappers que são usadas no “dia a dia”. Feito isso, podes definir uma área de atuação.
Quando me refiro a área de atuação, digo, Mobile, Desktop, Web…
ah to ligado. Já passei por essas apostilas. Você quer dizer a plataforma que eu quero seguir. Eu estava pensando inicialmente em desktop, depois poderia me aprimorar pra web, já que programar em Java pra web é um trabalho bastante chato. Tenho receio de não acompanhar direito as coisas hehe
Porque “bastante chato” ? Qual sua experiência com Java Web ?
Enfim, seguir uma área que tu acha “chata”, já não é um bom caminho. Se gosta de sistemas Desktop, vai fundo. É só dedicar estudos a este tipo de nicho.
Isso inclui as pesquisas sobre padrões de projetos com Desktop
nel, aqui no Nordeste falar que uma coisa é “chata” as vezes (que é o caso) significa dizer que é uma coisa complicada hehe. Eu vi bastante de uma apostila de Java Web da Caelum que inclusive abordava o framework Spring e cheguei bem a frente dela. É de fato muito promissor, mas eu gostaria de me aprimorar nesses padrões de projeto para não ter dores de cabeça quando precisar dar manutenção em um sistema. Sou muito exigente em fazer um código limpo e bem estruturado desde que comecei a programar, daí vem esse interesse nos padrões de projeto Java
Isso é correto. Mas o Spring é apenas um dos frameworks possíveis de serem usados em JEE. Tem um leque de opções bem significativo.
O que eu quis dizer, é que existem padrões de projetos específicos para cada área. Dê uma olhada: http://www.corej2eepatterns.com/
ServiceLocator, isso existe em Mobile? Faço a menor ideia.
Por isso estou dizendo, direcione os estudos a uma área e procure atuar nela.
Ser difícil pode ser uma vantagem, diminui a concorrência e pessoas que conhecem sobre a mesma
Padrões de Projeto - Soluções Reutilizaveis de Software Orientado a Objetos
Por incrível que pareça, o grande problema que eu vejo é você já ser experiente! Como você vem do delphi OO não é uma coisa muito natural e você tenderá a criar programas extremamentes procedurais, separando a logica de dados criando os famigerados BOs, TOs e usando DAO.
Esses livros vão te dar um bom feedback das melhores práticas. O primeiro é só uma introdução aos padrões de projeto mais básicos. O segundo contém os padrões mais comuns em aplicações corporativas e é um livro que todo o programador que trabalha com isso deveria ler. O terceiro livro é um que todo o programador deveria ler, ele ensina a como criar um dominio rico, ou seja modelar um sistema que represente fielmente a atividade para qual foi desenvolvido.
Como conselhos eu diria:
Nunca começe modelando pelo banco de dados! Comece organizando as suas classes, depois faça o mapemento delas para o banco de dados.
Não utilize DAO, BOs e TO. Crie um modelo de dominio e utilize um repositório.
Crie sempre testes, ou melhor utilize TDD efetivamente.
Tente separar bem as camadas e não criar acoplamento (Se você utilizar TDD seu acoplamento entre classes será baixo, mas poderá haver acontecer entre as camadas).
Vou dar uma olhada nesse livro aí que você mandou cara. Me responde uma coisa, vc que é JWizard: Existe muito trabalho pra migrar uma aplicação de Java SE para Java EE em termos de regras de negócio? Digamos que eu tenha um sistema de controle de o que quer que seja, eu vou ter muito trabalho pra fazer esse mesmo sistema, com as mesmas funcionalidades pra Web e Desktop por exemplo?
x@ndy, o pessoal fala muito bem dessa série use a cabeça, vou me acalmar e começar por ele mesmo pra depois seguir a sua orientação. Delphi é realmente muito procedural e apenas ver o quão bagunçado o código ficava, mesmo você tentando organiza-lo, isso me deixava doente. Deve ser TOC rsrs. Muito agradecido pelas dicas. Abraço.
Isso depende, se você separou bem as camadas, se usou MVC por exemplo, é tranquilo pois as regras de negócio estão todos na camada de dominio, então tanto faz você ter uma interface web ou desktop agora se você fez “Interface Inteligente” ou seja, as regras de negocio está junto com os formulários (como é feito muito no delphi) você terá um problemão.
Um jeito simples de saber se suas camadas estão acopladas é o que Martin Fowler fala no livro Padrões de Arquitetura de Aplicações corporativas:
[quote=Martin Fowler]
Uma das partes mais difíceis de trabalhar com lógica de domínio parece ser que as pessoas frequentemente acham difícil reconhecer o que é lógica de domínio e o que são outras formas de lógica. Um teste informal que gosto de aplicar é imaginar a adição de uma camada radicalmente diferente a uma aplicação, como uma interface em linha de comando a uma aplicação Web. Se, para fazer isso, você tiver que duplicar alguma funcionalidade, é um sinal de que a lógica de domínio vazou para a apresentação. De maneira semelhante, você tem que duplicar lógica para substituir um banco de dados relacional por um arquivo XML?[/quote]
Provavelmente, sim.
É claro que depende de algumas variáveis, mas eu diria que são coisas completamente diferentes, por mais que tu separe adequadamente as camadas.
Existem padrões que são extremamente aconselháveis a serem usados em Web, cujo padrões não podem ser utilizados em sistemas desktop.
Se falarmos em aplicações de grande porte, estamos falando em usar servidores de aplicação e não apenas um container Web.
Dessa forma, temos que buscar entender o máximo possível a especificação JEE, para que possamos segui-la e evitar maiores dores de cabeça.
Trabalhava com Glassfish quando foi decidido migrar para o JBoss 7.1.1. Tivemos alguns retrabalhos, pois cada AS tem suas peculiaridades, mas basicamente não foi em código e sim em configurações e isso porque procuramos seguir o máximo a especificação.
Então, tenha cuidado ao comparar desenvolvimentos que seguem linhas de raciocínio distintos. Obviamente, como o próprio x@ndy citou, quanto mais desacoplado seu código estiver, menor será o retrabalho. Por isso seguir boas práticas no desenvolvimento é essencial, independente para qual área deseja atuar.
Só para finalizar, a nível de apresentação, tu terá preocupações com eventos AWT entre outros, em relação a Web, você precisa definir o que vai usar e posso te falar colega, tem zilhões de opções.
[quote=ViniGodoy]Só um detalhe: O Delphi é uma linguagem orientada a objetos, e não procedural.
E OO é bem natural. Há muitos exemplos de padrões e boas práticas na VCL (que inclusive inspiraram boa parte da API do java).[/quote]
Ele não quer dizer que Delphi não seja OO e sim que criar programas em Delphi com UI gera programas bem procedurais.
E Viny, desculpa, mas OO não é nada natural para quem programava de maneira procedural. Digo isso pq levei um boomm tempo até realmente aplicar de maneira efetiva o paradigma!
Quando se começa a usar OO de quem veio do paradigma procedural é separar a lógica dos dados e gerar os famigerados BOs e TOs. Isso é uma praga que assola os sistemas não somente devido ao EJB 2, mas por que é extremamente natural para quem programava de maneira procedural.
Existe também o problema do acoplamento entre objetos! Acoplamento é algo que parece natural em procedural devido a dependência de bibliotecas, mas objetos não são bibliotecas!
E não podemos esquecer do coesão, embora também seja um problema no mundo procedural, possui um impacto maior ainda no paradigma OO.
A VCL realmente é fantástica, mas não considero Delphi a melhor linguagem para OO, principalmente pela falta de um gerenciamento de memórias efetivo e de intefaces indepententes do SO. Para se ter um sistema realmente OO isso é necessário implementar a contagem de referência (o João Morais, grande especialista sobre delphi, fala sobre isso [urlhttp://blog.joaomorais.com.br/2008/09/06/objetos-contagem-ref.html]aqui[/url]) na mão o que um porre e pode deixar cheio de memory leaks. Fora outros problemas como ele permitir que classes com métodos abstratos sejam instanciadas e não ser possível tornar o construtor privado!
Mas quem são as pessoas que programam de maneira procedural que você está falando? O Delphi não é uma linguagem procedural. Ele é orientado a objetos. Tem classes, interface, polimorfismo… A própria VCL implementa padrões de projetos como o observer, chain of responsability, mediator… Ou você se refere a programadores que vieram do Pascal (que não parece ser o caso do colega)?
Digo porque fui programador Delphi por anos. E usavamos OO normalmente. Aliás, meu primeiro contato com padrões de projetos ocorreram justamente por recomendação do manual da VCL. E foi o Delphi a linguagem que me fez migrar do paradigma estruturado para o OO. Foi nele que aprendi a usar polimorfismo, e que entendi para que serviam interfaces.
O artigo que você postou não fala nada sobre a necessidade de contagem de referências para se implementar um modelo realmente OO. Ele só mostra uma forma de implementar o mecanismo em Delphi. Gostaria de ver uma referência que relacionasse uma coisa a outra. No C++, por exemplo, existe OO sem contagem de referências.
Não vou negar que contar referências ou garbage collection simplificam muito o projeto (e daí, o artigo que vc postou e os smart pointers do C++) e que, de maneira geral, seja extremamente vantajoso ter contagem de referências. Mas contagem de referência nunca foi um requisito para um sistema ser orientado a objetos, e sistemas de performance crítica ou requisitos mais agressivos de memória frequentemente optam por não usa-la, mesmo pagando o custo da complexidade e risco de um memory leak.
Agora, programar estruturado em Delphi, é como programar estruturado em Java. Você pode criar um sistema em Java onde tudo esteja implementado na view, seja numa tela Swing ou num JSP, e praticamente deixar toda lógica dentro de event listeners. Isso é uma má prática em Java, assim como é em Delphi.
Ok… fazendo um mea culpa. Acho que sei de que programadores você está falando: boa parte dos programadores Delphi do Brasil não programam bem. Ou mantém sistemas legados mal escritos, de maneira procedural.
Infelizmente, a linguagem leva a culpa.
O Delphi não foi construído com MVC em mente. Mas MVC não é o único paradigma que se pode aplicar ao construir interfaces gráficas (o que não significa que outros sejam melhores). E creio que a linguagem acabou optando pelo paradigma errado (usar mediação através de componentes, e abusar bastante dos data bindings).
Mas é bom não confundir as coisas. MVC não é requisito para um sistema “verdadeiramente OO”. Existem outros tipos de arquiteturas, como a arquitetura de componentes (fortemente baseada em composição), que tem dado resultados tão bons ou até melhores do que o MVC.
De qualquer forma, é sim possível (e relativamente fácil) fazer um sistema bem dividido em camadas em Delphi. Entretanto, acho que o colega faz bem de sair da linguagem, afinal, ela já não é mais expressiva para o mercado, ou para a sua carreira.
Padrões de Projeto - Soluções Reutilizaveis de Software Orientado a Objetos
Por incrível que pareça, o grande problema que eu vejo é você já ser experiente! Como você vem do delphi OO não é uma coisa muito natural e você tenderá a criar programas extremamentes procedurais, separando a logica de dados criando os famigerados BOs, TOs e usando DAO.
Esses livros vão te dar um bom feedback das melhores práticas. O primeiro é só uma introdução aos padrões de projeto mais básicos. O segundo contém os padrões mais comuns em aplicações corporativas e é um livro que todo o programador que trabalha com isso deveria ler. O terceiro livro é um que todo o programador deveria ler, ele ensina a como criar um dominio rico, ou seja modelar um sistema que represente fielmente a atividade para qual foi desenvolvido.
Como conselhos eu diria:
Nunca começe modelando pelo banco de dados! Comece organizando as suas classes, depois faça o mapemento delas para o banco de dados.
Não utilize DAO, BOs e TO. Crie um modelo de dominio e utilize um repositório.
Crie sempre testes, ou melhor utilize TDD efetivamente.
Tente separar bem as camadas e não criar acoplamento (Se você utilizar TDD seu acoplamento entre classes será baixo, mas poderá haver acontecer entre as camadas).
Qualquer duvida, estamos ai![/quote]
Agora fiquei curioso, por que não usar?
Vou aproveitar a sugestão dos livros e ler também.
Mas quem são as pessoas que programam de maneira procedural que você está falando? O Delphi não é uma linguagem procedural. Ele é orientado a objetos. Tem classes, interface, polimorfismo… A própria VCL implementa padrões de projetos como o observer, chain of responsability, mediator… Ou você se refere a programadores que vieram do Pascal (que não parece ser o caso do colega)?
[/quote]
Realmente, eu vim do C. Não estou dizendo que Delphi não é OO. O problema é dele é o formato de UI onde você arrasta para tela um componente TConnection da vida, um TQuery e um TDataSet, parametriza as propriedades escreve a consulta no TQuery, coloca meia duzia de Data Controls e tem um crud pronto em menos de 15 minutos! Depois é só trabalhar em cima de alguns eventos e escrever alguns métodos para alguma regra de negócio específica.
Como é extremamente rápido fazer isso e criar um modelo OO é demoria muito mais tempo a UI vence. Claro que isso tem um preço a longo prazo e só quem já passou por isso e sabe as consequências de não utilizar OO no Delphi. Só que a grande maioria das empresas (eu atuei em várias como programador Delphi) preferem manter o legado do que começar uma refatoração e nem querem pensar OO. Como disse um ex-chefe meu “Objetos é coisa de acadêmico”! Isso cria uma cultura e quem vem dela tem dificuldades em entender o paradigma OO.
Também fui programador delphi por anos, na verdade utilizo ele até hoje! Só que acredito que você teve sorte. A maioria das empresas que utilizam Delphi não o fazem usando OO! Como disse antes a maioria mantém o seu legado procedural!
[quote=ViniGodoy]O artigo que você postou não fala nada sobre a necessidade de contagem de referências para se implementar um modelo realmente OO. Ele só mostra uma forma de implementar o mecanismo em Delphi. Gostaria de ver uma referência que relacionasse uma coisa a outra. No C++, por exemplo, existe OO sem contagem de referências.
Não vou negar que contar referências ou garbage collection simplificam muito o projeto (e daí, o artigo que vc postou e os smart pointers do C++) e que, de maneira geral, seja extremamente vantajoso ter contagem de referências. Mas contagem de referência nunca foi um requisito para um sistema ser orientado a objetos, e sistemas de performance crítica ou requisitos mais agressivos de memória frequentemente optam por não usa-la, mesmo pagando o custo da complexidade e risco de um memory leak.
[/quote]
Realmente não fala, a idéia foi colocar uma referência para uma implementação de contagem de referência que Delphi não tem. So que você já tentou fazer um sistema totalmente OO sem isso? É loucura, principalmente quando você tem inumeras classes compartilhadas! Existem outras formas mas a que custo? A complexidade aumenta tanto que você deixa de pensar no dominio para implementar outras coisas devido a restrições da linguagem. É possivel? Sim, mas vai ser um trabalho dos infernos!
Concerteza, mas isso acontece direto no Delphi! Acretido que a vantagem do java nesse caso é que eu nunca vi uma ferramenta tão boa para criar aplicações desktop quanto a do delphi e mesmo assim se vê muita bizarrice. Imagina só se swing tivesse alguns Data Controls :shock:
Só quero esclarecer que não considero o Java melhor do que Delphi até por que eu não acredito em melhor linguagem como escrevi aqui. Na verdade o delphi é uma linguagem fantástica e tem uma gama de recursos incriveis, porém não considero ela a melhor a linguagem para trabalhar com objetos devido a falta de gerenciamento de memória, permitir a instancia de um objeto abstrato e não permitir um construtor privado entre outros). É possivel criar programas OO no delphi? Sim, mas você vai ter uma dificuldade bem maior do que no java!
BOs e VOs e bem simples: Porque você esta programando de maneira procedural! Uma classe contém as regras de negócio a outra os dados então qual a diferença entre um conjunto de funções de uma biblioteca e um struct (ou record no pascal/delphi)? NENHUMA, pois um BO cheio de funções de negocio e um biblioteca cheia de funções fazem a mesma coisa já um TO (ou VO, como preferir) é quase igual a uma struct a um record exceto que esses não tem os métodos getters e setters que na verdade não servem para nada sendo mais fácil deixar os campos públicos!
Isso cria o chamado dominío anêmico onde se tem um conjunto de classes que não tem “responsabilidade nenhuma”, ou seja, um monte de clases burras!
BO e TO são uma bizarrice criada devido a arquitetura do EJB 2.0. Só que isso é tão natural para quem vem do mundo procedural e acha que sabe OO e então seguem utilizando esses padrões e, embora seja um padrão do java, já vi isso sendo utilizado até no PHP!
