[quote=mochuara][quote=sergiotaborda]
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.
[/quote]
Não precisou, vc mesmo fez, e foi destacado por mim em negrito alguns posts atras.
[/quote]
Ah! era isso ? Então qual é o defeito da linguagem java que o padrão Enumeration resolve ?
Então qual é o defeito da linguagem java que o padrão Bridge resolve ?
Então qual é o defeito da linguagem java que o padrão Registry resolve ?
Escolha um padrão qualquer e indique qual problema da linguagem, ele resolve.
[quote=ViniGodoy]
Depois, é bom lembrar que a VM só irá criar seu Singleton assim que for usado a primeira vez, pois será nesse momento em que a classe será carregada. Ou seja, o lazy loading já existe.[/quote]
Entenda que !!!
A implementação em java deste padrão deve ser utilizar um campo privado e estático do tipo da própria classe para armazenar a referencia da única instancia permitida, o qual deve ser inicializado de modo a indicar a inexistência de tal instancia.Um método estático, cujo tipo de retorno também é a própria classe, prove o ponto único de acesso a tal instancia. Se a operação de instanciação de um objeto da classe, garantimos a instancia única ao mesmo tempo que a criação, só ocorrerá quanto estritamente necessário(Lazy instantiantion)
[quote=sergiotaborda]
Ah! era isso ? Então qual é o defeito da linguagem java que o padrão Enumeration resolve ?
Então qual é o defeito da linguagem java que o padrão Bridge resolve ?
Então qual é o defeito da linguagem java que o padrão Registry resolve ?
Escolha um padrão qualquer e indique qual problema da linguagem, ele resolve.[/quote]
Ja foi dito que vc pode ser 2x mais produtivo numa linguagem mais alto nivel, que não precise usar patterns. O quemais vc precisa pra entender que todo o resto é balela?
[quote=mochuara]
Ja foi dito que vc pode ser 2x mais produtivo numa linguagem mais alto nivel, que não precise usar patterns. O quemais vc precisa pra entender que todo o resto é balela?[/quote]
Uma coisa que eu não entendo é porque você não se situa sobre Patterns, isso pode se estender a família da linguagem como também outras implementações que venha a surgir pelo o estudo da arquitetura, estou vendo que o Sérgio, se coloca tecnicamente mas você não tem profundidade sobre um case que lhe dê melhor representação.
[quote=mochuara][quote=ccaneta]
Uma coisa que eu não entendo é porque você não se situa sobre Patterns, isso pode se estender a família da linguagem como também outras implementações que venha a surgir pelo o estudo da arquitetura, estou vendo que o Sérgio, se coloca tecnicamente mas você não tem profundidade sobre um case que lhe dê melhor representação.
[/quote]
Pelo visto não é só escrever, vc tb não saber ler! :shock: [/quote]
Cadê o exemplo, cadê o argumento técnico, você esta redundante o tempo inteiro não estou vendo você se colocar tecnicamente é só isso, Design Patterns já algo comprovado , a forma que se faz implementação cria abstrações que vão sofrer mudanças mas isso não foge do entendimento da arquitetura para seu proposito, o que percebi é que você quer buscar redefinição e querer quebrar esses padrões, muito bem você pode fazer isso , alias linguagem que utilizam metaprogramação são anti-patterns, ao como beanshell mas não deixam de usar decorator para manipulação de tela, por exemplo ou sendo um design patterns de comportamento.
[quote=mochuara][quote=sergiotaborda]
Ah! era isso ? Então qual é o defeito da linguagem java que o padrão Enumeration resolve ?
Então qual é o defeito da linguagem java que o padrão Bridge resolve ?
Então qual é o defeito da linguagem java que o padrão Registry resolve ?
Escolha um padrão qualquer e indique qual problema da linguagem, ele resolve.[/quote]
Ja foi dito que vc pode ser 2x mais produtivo numa linguagem mais alto nivel, que não precise usar patterns.
[/quote]
É, foi dito, mas não provado. Nem um misero exemplo conseguem dar. Se fosse verdade choveriam exemplos.
É ridiculo dizer que Rails não é MCV, que não usa ActiveRecord ( o padrão) que ruby não usa MetaObject.
Todo o objeto JavaScript é criado por Prototype. Todos os objetos com propriedades em qualquer linguagem podem ser PropertyBag.
Mensageria , ESB usam Produtor-Consumidor. Toda a string é um Wrapper de array de characteres. Todos estes e mais são exemplos
de como os padrões formam as proprias linguagens OO, como os próprios mecanismos e definições seguem os mesmos padrões.
A razão é porque os padrão precedem as linguagens. Em todas vc pode criar um factory, um sigleton, um builder, um façade… pattern não é limitação de linguagens.
Isso é uma mentira inventada por mentcaptos e perpétuada por quem não tem condições de entender OO e se refugia na desculpa que entender OO e aplicar padrões é inutil e que é possivel programar bom codigo sem eles. Simplesmente não é.
Eu não estou tentando convencer vc. Vc é um caso perdido. Estou sou mostrando que vc não tem razão e o que afirma é falso e sem fundamento. Só para evitar que quem esteja lendo não cai na mesma asneira.
Então creio que é melhor não saber OO mesmo e essa sopinha de letrinhas toda. Tem muita gente mais esperta que eu que ganhou muito dinheiro com Delphi sem essa enrolaçao toda.
Pessoal, cada nova lida que dou nas discussões que surgiram desde a última vez que li, percebo porque Java possui tantos frameworks para: MVC, Persitência, Injeção de Dependências e por ai vai. Cada um tem uma visão do mundo, cada um com seu óculos “cor de rosa”. Logo, surgem uns que defendem o framework X porque implementa melhor os tais design patterns de que o outro não implementou direito.
A pergunta que fica é: Se querem repensar uma segunda edição, é porque muita coisa foi feita e de forma como não deveria, direito ao longo desses anos. Quem me garante que cada um dos porta-vozes que aqui falam sabem corretamente implementar tais design patterns sem erros?
Outra pergunta que fica é: Porque o criador do Rails, um framework genial por sinal, não escolheu Java ou .Net e sim Ruby? Ele poderia, mas porque não “KISS” :lol: ?
Não estou dizendo que padrões são desnecessários, mas estou dizendo que, termos diversos padrões ao mesmo tempo interagindo e, muitas vezes com efeitos refatorados, não dificultam o progresso do desenvolvimento e matam a criatividade? Um projeto Java necessita de diversos patterns mesmo ou temos casos que, ai vem a pergunta de R$ 1.000.000,00, em que os desenvolvedores repensam e refatoram os diversos patterns substituindo-os por menos?
Essas perguntas não querem sair da minha cabeça, pois vejo um tamanho tão grande de complexidade que, não me admira que um projeto besta leve 10 vezes mais para ser feito em Java com mais pessoas do que em Rails, com menos pessoas e todas entendendo seus códigos.
Na minha visão, a falha que aparece na maioria do entendimento das pessoas (incluindo eu) é querer “coisificar” os padrões como se tivessem vida própria. Patterns nada mais são do que soluções prontas pra problemas conhecidos.
A simples pergunta que você deve fazer antes de usar um pattern é “este pattern realmente foi feito para o problema que estou tendo?”. Depois disso basta fazer testes solucionando o seu problema com o Pattern escolhido. Se ele se mostrar eficiente para você aplique-o sem medo de ser feliz…
Outro ponto rídiculo que vejo é quando chego para dar manutenção em algum sistema mais antigo e vejo desenvolvedores/analistas/arquitetos/etc tocando o pau no sistema, dizendo que foi usada tecnologia obsoleta, padrões errados, mal codificação, etc, etc, etc…
Maioria falácia! O que acontece neste ponto é que sistemas mudam, regras de negócios mudam, negócios mudam, pessoas mudam, tudo muda o tempo todo…
Então como posso culpar as pessoas ou o sistema por ele estar errando em algo que ele não foi, desde sua concepção, proposto para solucionar?
Como posso culpar um cara que modelou um carro em 1970 dizendo que o carro é “beberrão” sendo que, na época o carro não foi proposto para não o ser???
É como eu chamar intelectuais que não conheciam a teoria da Relatividade de burros… Notem que até mesmo agora que estamos entrando na era do “Nano” a própria Relatividade de Einstein já não se aplica mais…
Ah! , mas padrões não mudam.
Existe sim o jeito certo e o jeito errado. Pensar e aceitar que todos os jeitos são certos é que é falacioso. Se todos os jeitos fossem certos não existia o conceito de gambiarra.
Sistemas são mal projetados sim. Os desenvolvedores por pressão, ignorancia, incompetência ou desleixo introduzem o que se chama de débito tecnico. Ou seja, a melhor solução tecnica não foi usada. Não porque se escolheu não usar, mas porque não se considerou procurá-la. Só pode não usar a melhor solução tecnica, pode usar a segunda melhor. Só não pode usar a primeira coisa que lhe vem ha cabeça.
Tecnologia tem obsolescencia determinada à partida. Struts é um bom exemplo. O modelo é overbloated , complexo demais para o que precisa ser feito. Era de esperar que se torne obsoleto. E a prova é que tornou de fato. Tem alguns até defendendo que é um anti-framework. Porque ele é uma porcaria ? Porque viola vários principios de OO e boas práticas. Por exemplo, a nomenclatura é um pesadelo.
ninguem culpa o sofware por ele não solucionar um problema de negocio que não era previsto. Se culpa a equipa por não ter solucionado - ou executado da melhor forma - a solução tecnica que dá estrutrua ao software para resolver os problemas de negocio.
Soluções ruins existem sim. Infelizmente são a maioria, porque não ha investimento em arquitetos e designers , esse papel é desempenhado por amadores.
Pesquise por “débito tecnico” (tecnical debt) para mais informação de como sim é comum e errado fazer software ruim
P.S. em relação à relatividade nem vou me pronunciar porque senão ficamos aqui a vida toda. Só como exemplo o GPS funciona graças à relatividade geral.
Sérgio, se eu entendi bem oq o mochuara quis dizer, é que ele acha inútil os desenvolvedores terem que conhecer alguns design patterns, pois eles podem muito bem serem implementados e aplicados como um sugar nas linguagens.
Você mesmo exemplificou que várias linguagens já fazem isso. Agumas através de um sugar, outras através de construções próprias, outras através da própria sintaxe da linguagem, que exige isso.
E nesse ponto eu concordo com o mochuara: existem alguns patterns que já poderiam ser nativos na linguagem, com uma construção MAIS simples ainda.
E eu reforço o MAIS simples, pq não vejo nenhum pattern como algo complexo. No máximo os seus conceitos são estranhos a programação procedural à qual a maioria esmagadora dos programadores são treinados.
Observação OFF-TOPIC: como temos filósofos no GUJ…
Eu concordo com você…heehhehehe… O problema é que meu problema pode mudar, aliás, ele vai inevitavelmente mudar! E ninguém quer que o Pattern previamente escolhido comece a se tornar um impencilho no meu negócio.
Então por isso eu digo: Padrões não mudam até que mudem…heheheheheh… O Pattern escolhido certamente não muda, mas meu negócio, minha infra, minha mente muda…
É exatamente esse aspecto que quis abordar. Dizendo que não é culpa do Pattern quando algo que ele não foi proposto pra resolver simplesmente chega.
Por exemplo, tenho um Pattern Y pra resolver um problema X. O Pattern, obviamente, vai ditar tudo que tenho que fazer para resolver o problema X (Afinal alguem que formulou o Pattern já passou exatamente pelo problema que estou passando).
Acontece que depois de um Ano o problema X se transforma num problema Xb (Minha loja farmácia além de vender remédios começou a prestar serviços (mão de obra de sei la o quê) e preciso lançar isso no sistema). Neste ponto o Pattern não mudou, até por que ele não tinha que mudar. Afinal ele é um Padrão! O problema é que neste ponto eu tenho escolhas.
Quebro o Pattern injetando código a moda “Miguelão” para resolver minha situação .
Procuro outro Pattern e, caso exista, refatoro minha aplicação com este novo Pattern.
Tento adaptar o Pattern, que obviamente deixará de ser o Pattern outrora escolhido para se converter em outro Pattern.
etc…
Enfim, creio que eu que estamos defendendo a mesma coisa…ehheheheh
[quote]
P.S. em relação à relatividade nem vou me pronunciar porque senão ficamos aqui a vida toda. Só como exemplo o GPS funciona graças à relatividade geral.[/quote]
Gosto do jeito que o livro “Use a cabeça! Padrões de projetos” aborda o assunto. Vai muito na linha do que o Luca falou, de ver o problema real, e aí tentar resolver, sempre tentando melhorar, talvez você caia num padrão… Particularmente, não gosto de começar a pensar em algum padrão para resolver o problema, se o mesmo nem chegou ainda… Não quero ser radical, claro que se vc quer isolar a criação do objeto vai usar algum factory e tal, mas se não for tão claro assim… eu programaria, tentaria resolver, e durante essa caminhada poderia perceber alguma coisa e “refatorar”, sim eu gosto de refatorar, prova que eu estou em melhoria continua :). De vez em quando eu vou me dar bem, de vez em quando eu vou falar: “puta merda, poderia ter usado isso antes”, acontece, faz parte do jogo :). E tambem pode acontecer com alguma escolha de padrão que vc fez… do tipo: previ que tinha de adicionar responsabilidades em tempo de execução a algum objeto, por isso usei o decorator(tomara que eu esteja certo :)), mas passou um tempo, não precisei adicionar nada e fiquei com classes a mais por uma razão que não vingou. Para mim, resumindo, programar tem muito de bom senso, e, como acho que tudo em excesso faz mal, vou pesando e decidindo o que tenho que fazer.
Vc está falando de um tipo diferente de padrão que não é de programação, é de modelo. Esse padrões são chamados Padrões de Aplicação ou Padrões de Analise. É um campo ainda pouco desenvolvido principalmente devido à fraca compreensão de OO entre as pessoas que conhecem os dominios. Mas temos alguns exemplos. Se vc trabalha com estoque (muitos sistemas trabalham com estoque) qual foi o padrão que vc usou para programar isso ? Nenhum ? Bom, ai já começa mal. Não foi pesquisar quais havia ? não tentou encontrar um nos N milhares de softwares que ha por ai ? Não se atentou à realidade para definir um modelo ? Estes padrões derivam diretamente da analise do negocio. O padrão para estoque é Account (conta). O mesmo que se usa em finanças e contabilidade. À partida pode não ser obvio porquê, mas é esse o padrão. O tipo de operações que se fazem nestes três ramos são semelhantes e contém regras comuns - teoricas e bem definidas e entendidas - como seja a regra de partidas dobradas.
O problema não evolui como vc explicou. O padrão não vai resolver o problema de negocio, nunca. O padrão vai resolver a tradução do modelo/dominio/regras para o software. Padrões de Analise como Account e Money têm implementação variadissima mas ninguem discute que são padrões de fato para resolver os desafios que se propõem.
Veja bem, se o problema é mutante no tempo, não ha realmente um padrão. E portanto não foi o padrão X que evoluiu para X’ e sim que o uso do padrão X foi precipitado. Não existia realmente nenhum padrão ali.
Mesmo assim, hoje em dia , é dificil que vc encontra um processo/modelo/entidade de negocio que nunca ninguém viu antes.
[quote=clone_zealot][quote=sergiotaborda]
É, foi dito, mas não provado. Nem um misero exemplo conseguem dar. Se fosse verdade choveriam exemplos.
É ridiculo dizer que Rails não é MCV, que não usa ActiveRecord ( o padrão) que ruby não usa MetaObject.
Todo o objeto JavaScript é criado por Prototype. Todos os objetos com propriedades em qualquer linguagem podem ser PropertyBag.
Mensageria , ESB usam Produtor-Consumidor. Toda a string é um Wrapper de array de characteres. Todos estes e mais são exemplos
de como os padrões formam as proprias linguagens OO, como os próprios mecanismos e definições seguem os mesmos padrões.
A razão é porque os padrão precedem as linguagens. Em todas vc pode criar um factory, um sigleton, um builder, um façade… pattern não é limitação de linguagens.
Isso é uma mentira inventada por mentcaptos e perpétuada por quem não tem condições de entender OO e se refugia na desculpa que entender OO e aplicar padrões é inutil e que é possivel programar bom codigo sem eles. Simplesmente não é.
Eu não estou tentando convencer vc. Vc é um caso perdido. Estou sou mostrando que vc não tem razão e o que afirma é falso e sem fundamento. Só para evitar que quem esteja lendo não cai na mesma asneira.
[/quote]
Sérgio, se eu entendi bem oq o mochuara quis dizer, é que ele acha inútil os desenvolvedores terem que conhecer alguns design patterns, pois eles podem muito bem serem implementados e aplicados como um sugar nas linguagens.
[/quote]
Alguns podem, mas não todos. E aqueles que são incluidos o são para facilitar. Não ha nada de errado com a linguagem que exija que se usem padrões. Padrões não são forma de remendar as limitações da linguagem. Esse é o ponto.
Se a linguagem x permite que vc implemente um padrão de forma simples ótimo, mas nem todos os padrões podem ser implementados pela linguagem. Por exemplo, java implementa o padrão Dynamic Proxy através da classe Proxy de forma simples e OO. Alguma outra faz isso ? Como vc faria um proxy dinamico usando a linguagem (não a API) ? Escolha uma onde isso é possivel e apresente. Em javascript, por exemplo, o padrão Proxy é impossivel porque não existe o conceito de contrato (interface) na linguagem nem na API. Vc não tem como fazer um objeto passar por outro de forma dinamica (tem o padrão decorator, mas é mais trabalhoso que em java).
Os pontos que quero deixar claros são :
Padrões não são forma de remendar as limitações da linguagem
A implementação, seja sugar ou normal ou via APi já pronta, não é relevante ao padrão. A implementação não faz parte do padrão.
Sérgio, como eu escrevi na minha primeira postagem deste tópico. Que a gente tem a mania de “coisificar” padrões. Padrões são padrões dentro ou fora de uma linguagem de programação. Indiferente da granularidade que ele apareça…
Se eu citei um padrão de modelo de negócio ou um padrão de sei lá o que, isso pouco importa. O ponto aqui é que a natureza nos ensina que tudo muda o tempo todo. Portanto, o problema que meu padrão resolvia elegantemente ontem, pode não resolver elegantemente hoje, ou até mesmo nem resolver.
Em momento algum eu disse que o Pattern é mutante. O que eu disse é que o problema que ele resolve de forma padronizada é mutante. Mesmo que não pareça ser, ou até possa não parecer durante séculos, mesmo assim tenho que saber que ele é mutante. O problema é mutante e o padrão não!
Eu posso ter um Pattern que me resolve um problema muito bem na ordem granular do meu negócio, o problema aqui é que em algum momento esse padrão de ordem granular pode começar a conflitar com a necessidade do “Macro” problema. Logo, ele passará a não ser a solução mais viável pro meu “macro problema”.
Concordo plenamente, mas aqui envolve uma série de outros problemas. Nem sempre quem resolveu um problema divulga a forma como resolveu. Nem sempre se tem tempo para pesquisar, o tempo todo, soluções para problemas que estamos tendo.
E ainda, por mais que problemas sejam compartilhados aos montes, na maioria das vezes não são lisamente iguais.
Eu posso ser um arquiteto, descobrir como outros arquitetos la na Europa estam resolvendo problemas de engirecimento de cimento e adotar aqui. Mas de repente a solução dada lá não necessariamente será a melhor a ser usada aqui.
Pois aqui terei uma temperatura diferente, nivel do mar diferente, umidade do ar diferente, estações do ano diferentes… E por ai vai…
Pelo que entendi, você defende que os padrões não são uma boa coisa pois apenas estariam compensando uma deficiência na linguagem. Que as linguagens teriam por obrigação implementar os design patterns.
E se pensássemos de uma outra maneira? A linguagem que implementa de forma nativa algum padrão não está simplesmente cumprindo sua obrigação: ela foi um passo além, adicionou um recurso a mais para facilitar nossa vida.
(Ou como se gosta de dizer nas empresas, foi “pró-ativa”).
Se você é mais produtivo com a linguagem X do que Y, não considere como um defeito de Y e sim como um mérito de X; pois ela está mais em sintonia com as suas necessidades e implementou os recursos adequados para elas.
Tampouco seria correto dizer que esses recursos da linguagem X são errados em outras linguagens, apenas porque precisam ser implementados pelo desenvolvedor.
Isso não é possivel. O meu ponto é que se isso acontece é porque o padrão foi mal identificado. Se ele resolver um problema ele resolve para sempre. é da sua natureza ser eterno, no sentido que não ha outra solução melhor. Mais uma vez, foi o uso do padrão que foi percepitado.
Dê exemplos. Do ponto de vista abstrato isso não faz sentido.