[quote=sergiotaborda]
Isso não é uma implementaçao da linguagem, é o uso da linguagem da mesma forma que em java vc usa a linguagem.
Implementado na linguagem seria como o object do scala. se vc declara class vc está dizendo que pode criar muitos objetos - modo normal, mas se vc declara como object (palavra chave) o scala sabe que aquilo é um singleton. Por isso que eu falei que a linguagem pode dar suporte, mas não pode dar suporte a todos os padrões. [/quote]
Seria como object se fosse implementado em Scala. E seria como lisp se fosse em Clojure. Essa distinção se é implementado na linguagem ou não é irrelevante se o objetivo foi alcançado e com menos esforço.
Comece pelos mais usados. Só de vc pesquisar quais são, vai estar entendendo melhor o motivação de cada um.
Patterns são apenas boas práticas, estão aí para facilitar nossa vida.
Portanto, se o pattern estiver facilitando sua vida está sendo usado de forma correta, agora se estiver atrapalhando está no lugar errado.
[quote=bruno_rg]Recomendo a leitura do Head First Design Patterns. Lá tem um monte de exemplos em Java. Depois de ler este é mais fácil entender o livro do GoF.
[/quote]
Este livro realmente é muito bom. Li e estou lendo mais uma vez para agora fazer o TCC.
Ao mesmo tempo estou fazendo a primeira leitura do livro do GoF, na qual julgo (até o momento) uma ótima referência no assunto.
Nele cada padrão tem um “frequency of use”, você pode usar como base pra ver quais os mais usados.[/quote]
Vou analisar este site. Realmente é algo novo e acredito que pode ser bem útil no desenvolvimento.
[quote=bobmoe]Comece pelos mais usados. Só de vc pesquisar quais são, vai estar entendendo melhor o motivação de cada um.
Patterns são apenas boas práticas, estão aí para facilitar nossa vida.
Portanto, se o pattern estiver facilitando sua vida está sendo usado de forma correta, agora se estiver atrapalhando está no lugar errado.[/quote]
Essas dúvidas surgiram conforme o caminhar do desenvolvimento do trabalho. Acredito que hoje tenho muito mais facilidade em enxergar e aplicar um padrão do que outro. Acredito que esteja faltando ainda é experiência deles dentro de um sistema, já que o mal uso, posso comprometer a qualidade do código ou entrar em uma fria.
[quote=LedRenan]
Essas dúvidas surgiram conforme o caminhar do desenvolvimento do trabalho. Acredito que hoje tenho muito mais facilidade em enxergar e aplicar um padrão do que outro. Acredito que esteja faltando ainda é experiência deles dentro de um sistema, já que o mal uso, posso comprometer a qualidade do código ou entrar em uma fria.
Agradeço as sugestões. :)[/quote]
Vc poderia pegar frameworks ou sistemas bem sucedidos e explicar que “tal coisa é possível ser feita daquela maneira tão elegante por que usa o pattern tal…”
Por exemplo, no caso do Hibernate você poderia dizer que a opção lazy usa o pattern Proxy e isso facilitou a implementação por tais motivos…
Com certeza. Por isso sou a favor da legalização de algumas drogas.
Padrões de projeto assim como a guerra contras as drogas ambos não resolvem os problemas mais difíceis.[/quote]
Design Patterns não existem para resolver os problemas mais difícies. Cada Padrão é uma solução que pode ser replicada para um problema conhecido em um contexto específico.
Se um problema tem uma solução que não pode ser replicada quando esse mesmo problema ocorrer em outra ocosição então não existe um pattern para essa solução.
O problema é que muita gente quer utilizar patterns para casos que não são aplicáveis.
O problema da abordagem de padrões não é nem seu uso excessivo (também ocorre). Mas a maneira como encaramos ela.
Idealmente, deveríamos primeiro pensar no problema, encontrar uma solução possível e, caso faça sentido, usar um pattern. Infelizmente, esse não é o caminho utilizado por numerosos desenvolvedores. Pra eles, interessa saber que: vamos usar um MVC aqui, vamos utilizar o Singleton para manter um único objeto desse, depois, usaremos um DAO, e um Façade; e finalmente a pergunta: “como vamos resolver o problema?”.
Percebe? Cada vez mais as pessoas preferem se manter presas num pacote de patterns antes de pensar na solução, pois dá-se uma impressão de um processo prescritivo, algo que, com software, não existe. Por isso é que tá cheio de gente no GUJ perguntando sobre Repositories, DAO ou MVC, enchendo o saco pra que deem a eles a receita de bolo pra usar em seus projetos, mesmo as pessoas respondendo que tudo depende.
[quote=Leonardo3001]O problema da abordagem de padrões não é nem seu uso excessivo (também ocorre). Mas a maneira como encaramos ela.
Idealmente, deveríamos primeiro pensar no problema, encontrar uma solução possível e, caso faça sentido, usar um pattern. Infelizmente, esse não é o caminho utilizado por numerosos desenvolvedores. Pra eles, interessa saber que: vamos usar um MVC aqui, vamos utilizar o Singleton para manter um único objeto desse, depois, usaremos um DAO, e um Façade; e finalmente a pergunta: “como vamos resolver o problema?”.
Percebe? Cada vez mais as pessoas preferem se manter presas num pacote de patterns antes de pensar na solução, pois dá-se uma impressão de um processo prescritivo, algo que, com software, não existe. Por isso é que tá cheio de gente no GUJ perguntando sobre Repositories, DAO ou MVC, enchendo o saco pra que deem a eles a receita de bolo pra usar em seus projetos, mesmo as pessoas respondendo que tudo depende.
Este mundaréu de padrões que tentam jogar em cima de quem começa a programar é um dos males do Java atual. Já acho isto faz tempo e até tive rapidamente a oportunidade de falar isto com o Paulo na última vez que almoçamos juntos. Seria muito melhor deixar a criatividade fluir e tentar resolver o problema. Tentem. Pode até ser que reinventem a roda ou encontrem dificuldades. Mas tentem antes de que algum cara que escreve complicado sugira o uso de algo que a gente só entende depois que sofre na carne.
Como eu disse para o Paulo, o estudo dos padrões não deve preocupar o desenvolvedor que ainda não é um bom programador. Antes de estudar padrões é preciso conhecer a API do Java, ler o Effective Java e entender coisas como as vantagens de desenvolver para interfaces.
[quote=bobmoe]
Patterns são apenas boas práticas, estão aí para facilitar nossa vida.
Portanto, se o pattern estiver facilitando sua vida está sendo usado de forma correta, agora se estiver atrapalhando está no lugar errado.[/quote]
Exato. Porque se o pattern fosse ruim ele seria anti-pattern. :lol:
[quote=marcosalex]
Como toda boa prática, se a pessoa não souber aplicar, o remendo fica pior. É o mesmo problema dos GPs que estudam o PMBok mas não sabem aplicar as técnicas. Ou do ITIL.[/quote]
A menos que o objetivo seja passar numa entrevista eu considero estudar patterns perca de tempo, principalmente pra um júnior, com o risco de ser traumático.
Só para exemplificar com um pattern pode ser usado incorretamente.
Dois contextos diferentes: sala de uma residência e sala de reunião.
Problema: Pessoas precisam entrar e sair da sala.
Solução: Deixar um buraco para que as pessoas passem (solução ruim) ou, colocar uma porta (solução padrão).
A aplicação da porta no contexto sala de reunião resolve um problema, mas acaba gerando outro.
Para saber se uma sala está em uso as pessoas precisam bater e abrir a porta e acabam interrompendo a reunião.
Portanto os arquitetos tiveram que pensar em uma solução diferente. Daí surgiu a porta com pequena janela de vidro. Por fim essa porta virou padrão para salas de reunião.
Da mesma forma a solução de porta com a janela de vidro não é uma solução boa se aplicada na sala de uma casa.
Isto é valido para qualquer tipo de pattern inclusive patterns de OO.
[quote=bobmoe]
Patterns são apenas boas práticas, estão aí para facilitar nossa vida.
Portanto, se o pattern estiver facilitando sua vida está sendo usado de forma correta, agora se estiver atrapalhando está no lugar errado.[/quote]
Vamos deixar algo muito claro: Patterns não são boas práticas.
Existem patterns e existe a boa prática de os usar. São duas coisas separadas.
A boa prática está relacionada ao aprendizado e utilização dos padrões e não aos padrões em si.
O padrão em si é uma solução comprovada e canónica para um problema recorrente.
Pegando a OO e as regras que a regem (principios vários) e dado um problema vc encontra um design tal que o
problema é solucionado com o minimo de efeitos secundários para em certo contexto de uso. Isto é um padrão.
Padrões formam uma linguagem. Existem regras para definir e falar essa linguagem (como no português),mas isso
não significa que sejam “falados” corretamente. Falar corretamente é que seria a boa prática.
