[quote=eduveks]Sinceramente eu nunca liguei para patterns, pois acho que faço um código bem estruturado, e vejo patterns um pouco como dar nome “cientifico” para as boas maneira de como os bons programadores estão resolvendo problemas.
E já aconteceu várias vezes de virem me dizer que há bacano você esta usando o pattern X, Y, Z, e eu nem imagina por completo desconhecimento do pattern, talvez até, nem o estivesse usando da maneira mais correta e nem resolvendo meu problema da maneira mais correta e prática. Penso que esta situação já deve ter acontecido com muitos, de alguém vir e dar um nome a maneira como tens o código.
[/quote]
Padrões são uma linguagem. Quando o cara fala “padrão X” , duas palavras ou três, isso poupa um monte de conversa.
Exactamente! padrões poupam tempo, poupam erros, poupam refactoring (correções) e por consequencia poupam dinheiro.
Tão simples assim.
Esta é outra falácia comum. Padrões são agnosticos à linguagem. Padrões são usos abstratos dos principios de OO. São como cololários ou desses principios, ou regras empiricas já encontradas e testadas por muitos. Em catálogos de padrões vc tem a descrição e solução do problema do ponto de vista OO. Mas em cada linguagem vc usará os constructos dela para implementar o padrão. A implementação depende da linguagem, o padrão não.
Um exemplo simples disto é o singleton Em java é preciso desenhar a classe de um certo jeito. Em scala vc declara isso explicitamente trocando a definição de “class” por “object”. o for extendido do java é o mesmo tipo de sintax sugar mas para o padrão Iterator.
Padrões não são sinais de lacunas nas linguagens pois eles existem “antes” das linguagens.
Todo o JDBC é implementação de Bridge voltada a banco de dados.
Todo o JMS é implementação de Produtor-Consumidor
Todo o JMX é implementação de MetaObject
Todo o JNDI é implementação de Registry.
Todo a Servlet API é implementação de ChainOfResponsability (lembrar que HTTPServlet é uma especialização da API para HTTP. A API em si é mais generica)
Padrões são abstratos. Implementações são concretas e podem ser tão complexas ou simples quanto necessário.
O uso de padrões não é um defeito da linguagem.
É o uso do padrão , ou a implementação, que podem ser errados, não o padrão em si.
ServiceLocator não tem nada de errado. InicialContext do JNDI é um service locator. E containers DI usam service locator para integrar com JNDI. É o padrão natural nesta situação. Não ha outro jeito.
Mas se vc semeia acesso estático ao locator, ai sim vc está comentendo erro. E é isso que virou anti-pattern o uso de ServiceLcoator.getLocator(). se a implementação do service locator não fosse global, não haveria problema .
Eu acho que entendo o Luca quando ele diz que devemos focar no problema, na minha opnião eu gosto sim e acho bom usar padroes o problema é fazer POP programação orientada a padroes, vamos a uma suposição para melhor entendimento:
“Preciso fazer uma calculadora que some 2 numeros, bom acho que vou precisar de 2 variaveis inteiras, entao eu faço o metodo X que recebe as variaveis…” ou seja estou pensando em resolver o problema, e entao em certo ponto(conhecendo eu os padroes) “epa espera ae, aqui caberia o uso do padrao X, certo entao vou usar o padrao X para o codigo ficar mais estruturado”
Pronto, esta maneira eu considero ideal.
O outro ponto que acho que o Luca quis falar(posso estar enganado) é o seguinte.
“Preciso fazer uma calculadora, certo deixa eu consultar meu cookie book de padroes pra ver qual padrao serve pra fazer calculadora, humm X serve… nao Y…talves…” Ou seja eu NAO estou focando em resolver o probema em si, mas estou pensando apenas no padrao, ao inves de procurar resolver o problema que é somar 2 numeros eu estou ja querendo procurar um padrao, mas o cliente deseja é somar numeros.
[edit adicionando]
Ai fica a questao, devo ir resolvendo o problema e encontrando os padroes em tempo de desenvolvimento e assim estruturando o codigo, ou devo parar tudo e ja querer achar padroes sem ao menos me preocupar com o problema e como resolve-lo???
[quote=fredferrao]O outro ponto que acho que o Luca quis falar(posso estar enganado) é o seguinte.
“Preciso fazer uma calculadora, certo deixa eu consultar meu cookie book de padroes pra ver qual padrao serve pra fazer calculadora, humm X serve… nao Y…talves…” Ou seja eu NAO estou focando em resolver o probema em si, mas estou pensando apenas no padrao, ao inves de procurar resolver o problema que é somar 2 numeros eu estou ja querendo procurar um padrao, mas o cliente deseja é somar numeros.[/quote]
Isso!
E ainda acrescento diálogo o que já assisti. Ao ser apresentado ao problema um programador começa a orientar o outro:
Aqui você usa um composite mais um facade e depois junta tudo com um command. Então é só fazer os DTOs e DAOs e resolver os Service Locators
Resposta do outro programador que ainda estava pensando com a linguagem ubíqua do negócio:
Ahã??? Tem banheiro neste andar?
Pois é, infellizmente na nossa área há gente arrogante que gosta de humilhar o colega arrotando padrões e siglas. Aprenda a explicar para o colega usando a linguagem que ele entende. Se ele entende padrões, então é ótimo. Mas não imponha o uso de padrões porque há muito programador EXCELENTE que não conheçe padrões mas são do tipo Get Things Done and Working (eu conheço pelo menos 2 assim)
Os primeiros problemas a resolver são de algoritmo e de fluxo de informações. É preciso testar a solução. E com algum código para mostrar fica mais fácil parear e fazer revisão de código.
Não há que ter medo de jogar código fora. Joguem quantas linhas forem preciso. Entendam, isto não é gamb. Gamb é querer acertar a solução SEMPRE logo desde o primeiro código escrito. Será que todo mundo aqui programa igual ao Joshua Bloch? E eu duvido que o Joshua Bloch olhe para o céu e acerte o código correto logo de cara.
E usem o que tem de bom nas técnicas atuais de programar: TDD, revisão de código aos pares (não usando sempre os mesmos pares), discussão da solução na tela branca, etc.
Se outra linguagem permite criar o mesmo programa sem precisar usar esses padrões JDBC, JMS, JMX, JNDI, vc tem um código menor e mais expressivo que levou metade do tempo pra fazer dando chance pra sair na frente da concorrencia que usa Java. Se é defeito ou não da linguagem fica a seu critério depois de passar por essa experiencia.
Se vc ama tanto padrões assim ok, mas ser obrigado pela linguagem a usar padrões para criar programas é um defeito da linguagem sim (na verdade, do programador por não saber escolher a ferramenta certa).
[quote=fredferrao]
Ai fica a questao, devo ir resolvendo o problema e encontrando os padroes em tempo de desenvolvimento e assim estruturando o codigo, ou devo parar tudo e ja querer achar padroes sem ao menos me preocupar com o problema e como resolve-lo???[/quote]
Uma vez vi uma apresentação sobre como um processamento batch que consumia vários dias foi convertido para um que consumia algums minutos. A solução apresentada não referia nenhum padrão. Era uma solução empirica (i.e. encontrada por tentativa e erro e evolução sequencial ). foi explicado como o processo normal que seria feito num for é substituido por várias threads (até aqui tudo bem) mas que isso influencia no contexto de persistencia e nas dependencias entre as instancias. A solução encontrada foi utilizar 2 niveis de cache (além do cache do hibernate). No fim era proposto que o processamento poderia ser destribuido em várias máquinas usando JMS. Chegar nesta conclusão demorou alguns anos e foi necessária devido a vários problemas encontrados durante esse tempo.
Agora, se vc pensar que um processo batch é uma unidade de trabalho (um pacote) e que a performance será aumentada distribuindo o processamento em threads simplesmente consultando o catalogo de padrões vc entende que tem que usar Produtor-Consumidor e UnitOfWork. Sabendo isto, vc pode criar seu miniframework de produtor-consumidor ou vc pode usar um já pronto (JMS). A implementação de UnitOfOWork já é baseada em niveis de cache que são partilhados conforme a transação.
Vc chega nas mesma conclusões em minutos. no máximo dias. Não anos.
Pensar com padrões é um tipo de pensamento logico-matemático que leva a conclusões confiáveis. E evita perda de tempo.
A multiplicação é a soma repetida do mesmo numero. Mas ninguem faz essa soma. Um padrão melhor foi encontrado para esse tipo de soma, e hoje é uma operação fundamental.
Moral da historia: vc só vai perder tempo implementando por tentativa e erro se está fazendo algo completamente original que nunca ninguem fez. Na maioria dos casos já alguem (muitos alguens) fez isso antes e existe um padrão. Procurar nos catálogos é bem mais rápido que tentar inventar do zero.
Se outra linguagem permite criar o mesmo programa sem precisar usar esses padrões JDBC, JMS, JMX, JNDI,
[/quote]
que fique bem claro : essas coisas são tecnologias. São biblotecas. Mas elas são feitas baseadas em um padrão. ou seja, elas são assim não porque alguem estipulou assim, mas porque estão seguindo um padrão que já existia antes.
[quote]
ser obrigado pela linguagem a usar padrões para criar programas é um defeito da linguagem sim (na verdade, do programador por não saber escolher a ferramenta certa).[/quote]
Dê exemplos.
Ninguem é obrigado a usar padrões. Tanto isso é verdade que é possivel fazer gambs horriveis , programar procedural, etc… se java, ou qq linguagem impusesse esse tipo de regras várias coisas seriam imposisveis (smalltalk está mais perto de ter essa restrição, mas mesmo assim ela não força o uso de padrões)
Em scala , ninguem o obriga a usar “object” para definir singleton. vc pode fazer do jeito que faria em java, mas usar a feature da plataforma é melhor porque é mais garantida. Mas é uma escolha de implementação. O uso do padrão singleton vc já identificou antes de escolher a linguagem. Em java 1.4 se vc quer usar o padrão Enumeration vc precisa criar um codigo cheio de detalhes e cuidados. O padrão é excelente, mas a implementação é complexa e perigosa. Em java 1.5 a implementação é trivial porque a plataforma cuida de todos os detalhes. É o mesmo padrão, supre a mesma necessidade e resovler o mesmo problema da mesma maneira, mas são duas implementações diferentes.
Dê alguns exemplo de onde a linguagem, e não o modelo , o obrigam a usar padrões.
Mas antes de perder tempo dando exemplos pense em alguns exemplos, pense se possivel fazer sem seguir o padrão ou usando gamb. Voilá, o padrão não é mais necessário. Dê exemplo apenas daqueles que vc tem mesmo que usar um padrão.
Luca, realmente pensar em padrões da forma que você e o fredferrao estão colocando - ou seja, o uso dos padrões é mais importante que a resolução do problema - é complicado. Só que esse argumento não deve ser usado pra descartar seu uso. Como o Sérgio falou, os padrões, antes de serem utilizados, devem ser estudados, para que o desenvolvedor identifique sem esforço - e sem ficar catando pelo livro - qual o padrão que melhor se adequa ao problema que ele quer resolver, ou nenhum se for o caso. Conhecê-los é útil sim, e aplicá-los também, desde que sejam aplicados nas situações que os exigem de fato.
[quote=sergiotaborda] Em java 1.4 se vc quer usar o padrão Enumeration vc precisa criar um codigo cheio de detalhes e cuidados. O padrão é excelente, mas a implementação é complexa e perigosa. Em java 1.5 a implementação é trivial porque a plataforma cuida de todos os detalhes. É o mesmo padrão, supre a mesma necessidade e resovler o mesmo problema da mesma maneira, mas são duas implementações diferentes.[/quote]
Nesse ritmo quando vc acha que Java ira implementar por exemplo o MetaObject do Ruby? Java 8, 10, 12?
Tudo bem, não é defeito da linguagem Java então, ainda assim meu cliente não pode esperar pelo Java 22.4 e eu valorizo meu tempo o suficiente pra evitar sempre que possível implementaões complexas e perigosas.
Acho que em momento nenhum descartei usar padrões (apesar de não gostar de alguns deles incluindo o Singleton, que antes de usar recomendo cuspir no chão 3 vezes e ainda acender 3 velas a N.Sra do Software que não Escala).
Uma idéia que me incomoda faz tempo sobre a questão dos padrões no Java é a mentalidade das pessoas de primeiro tentarem descobrir serventia para os padrões antes de pensar no problema.
E o tanto que o Java ganhou de complexidade depois que acharam que software para ser bom precisa usar padrões. O cara nem leu o Effective Java e já quer tacar Business Delegate no pão no café da manhã.
Acho sempre que primeiro a gente deve tentar escrever um código que resolva nosso problema. Se o cara é bom de padrões, então use-os logo de cara (é óbvio que sem arrotar conhecimento para cima da equipe). Mas eu acho mais legal quando alguém mostra o código para outro e este diz: olha, aqui poderia ser usado o padrão tal e tal. Ou, já temos em nossa base algo parecido. Uma das melhores práticas de hoje em dia é a revisão de código em pares.
Acho errado o cara primeiro procurar se existe algum padrão em algum suposto catálogo (*) antes dele mesmo pensar na solução
(*) Imagine a catástrofe se por azar o catálogo do cara é a primeira edição do Core J2EE Patterns…
Sim, isto é fundamental em programação Java pelo fato da linguagem so conter os padrões mais imbecis tornando tudo muito improdutivo. Os padrões mais úteis vc deve conseguir separado por meio de bibliotecas, ou fazer na mão vc mesmo. Apesar de haver uma cultura entre os programadores Java de que padrões é conhecimento util a verdade é, não é. O bom programador escolhe a linguagem certa para o problema, que significa a linguagem ja conter as abstrações necessárias para que apenas o código correspondente a aplicação seja necessário ser dito para o compilador.
A comunidade java não sabe brincar! Ela adora um evangelismo… é só surgir um novo evangelista pregando X que vai todo mundo atrás. É tudo ao extremo, não sabem moderar. Não adianta dizer que a culpa é dos programadores que não entenderam direito… a comunidade java gosta de modinha (incluindo eu,rsrs). A maioria dos desenvolvedores não são estes seres super espertos que saberao escolher adequadamente os patterns. Em geral, quando aprendem os patterns, levam sempre para o lado emocional. Sempre foi assim e vai continuar…
Vou voltar a dizer : os padrões , os catálogos, as pessoas que usam padrões corretamente, as equipas que conversam usando padrões, nada disto tem culpa que existam desenvolvedores que não sabem. O que deveria ser defendido por todos é que os padrões devem ser aprendidos e os desenvolvedores devem aprendê-los. Quem não o fizer sempre será um desenvolvedor pior do que poderia ser.
Veja bem, principios de OO é a matemática básica e patterns é como matemática avançada. Se vc sabe o básico vc vai longe, vai a qualquer lugar, mas demorará sempre que encontrar um problema complexo. Vc pode usar o básico para criar qualquer coisa, mas o esforço não será o mesmo que alguem que sabe a matemática avançada. Para estes o problema é trivial e os problemas que eles encontram que necessitam de esforço são muito mais complexos. Sistema CRUD podem ser feitos com o básico, mas são feitos com menos esforço usando padrões.
Design não é para todos. É por isso que é preciso um designer (designer OO, não de UI). quantos mais designer a equipe tiver mais fluido será o desenvolvimento. Design não é algo para se deixar com estagiários e juniors. Eles não têm maturidade conceptual suficiente para isso. Contudo, algumas pessoas simplesmente são talentosas, portanto tb não podemos descartar à partida os que essas pessoas dizem. O ponto é que para elas comunicarem, tem que comunicar no nivel do resto da equipa e patterns dá uma boa base para isso.
Vou voltar a dizer : os padrões , os catálogos, as pessoas que usam padrões corretamente, as equipas que conversam usando padrões, nada disto tem culpa que existam desenvolvedores que não sabem. O que deveria ser defendido por todos é que os padrões devem ser aprendidos e os desenvolvedores devem aprendê-los. Quem não o fizer sempre será um desenvolvedor pior do que poderia ser.
Veja bem, principios de OO é a matemática básica e patterns é como matemática avançada. Se vc sabe o básico vc vai longe, vai a qualquer lugar, mas demorará sempre que encontrar um problema complexo. Vc pode usar o básico para criar qualquer coisa, mas o esforço não será o mesmo que alguem que sabe a matemática avançada. Para estes o problema é trivial e os problemas que eles encontram que necessitam de esforço são muito mais complexos. Sistema CRUD podem ser feitos com o básico, mas são feitos com menos esforço usando padrões.
Design não é para todos. É por isso que é preciso um designer (designer OO, não de UI). quantos mais designer a equipe tiver mais fluido será o desenvolvimento. Design não é algo para se deixar com estagiários e juniors. Eles não têm maturidade conceptual suficiente para isso. Contudo, algumas pessoas simplesmente são talentosas, portanto tb não podemos descartar à partida os que essas pessoas dizem. O ponto é que para elas comunicarem, tem que comunicar no nivel do resto da equipa e patterns dá uma boa base para isso.[/quote]
ZZZZZZZzzzzzzzZZZZZZZ…
Besteira, patterns não são teoremas. São ferramentas projetadas por humanos assim como pontes e sapatos. E uma ponte que desaba é ruim, um sapato que da calo é ruim, patterns que atrapalham minha produtividade tb são ruins. Esse papo de mundo parelo onde descansam eternamente os padrões bonzinhos não é relevante pra discussão atual.
[quote=mochuara]
Besteira, patterns não são teoremas. São ferramentas projetadas por humanos assim como pontes e sapatos. E uma ponte que desaba é ruim, um sapato que da calo é ruim, patterns que atrapalham minha produtividade tb são ruins. [/quote]
Até agora vc não conseguiu produzir exemplos de como patterns atrapalham a produtividade ou de como são remendos das deficiências das linguagens. Ai fica dificil aceitar que isso é verdade.
Padrões não são ferramentas. Padrões são coisas que se repetem. Vc comparou com pontes. Padrões não são pontes, são coisas que se repetem em todas as pontes. (lembre-se que o conceito de catalogo de padrões veio exatamente da arquitetura)
[quote=mochuara]
Besteira, patterns não são teoremas. São ferramentas projetadas por humanos assim como pontes e sapatos. E uma ponte que desaba é ruim, um sapato que da calo é ruim, patterns que atrapalham minha produtividade tb são ruins. Esse papo de mundo parelo onde descansam eternamente os padrões bonzinhos não é relevante pra discussão atual. [/quote]
Vamos entender o seguinte, Design Patterns é algo produzido através de observações e abstração ao projeto que atingiram maior proficiência com o uso da linguagem envolvida e isso implica em suas versões e gerações que foram tendo especificações aprimoradas e facilitadas, sendo algo que é aproximadamente testado e cientificamente aceitável, todavia a visão ao projeto que vamos recorrer depende dessa evolução que é condicionada aos padrões é a sua melhor intenção, no que cabe ao design para aquilo é propicio ao seu uso.
Não precisou, vc mesmo fez, e foi destacado por mim em negrito alguns posts atras.
[quote=sergiotaborda]
Padrões não são ferramentas. Padrões são coisas que se repetem. Vc comparou com pontes. Padrões não são pontes, são coisas que se repetem em todas as pontes.[/quote]
Hm… legal, mas… e ai? Padrões não são ferramentas porque mesmo?
