Armadilhas para desenvolvedores (ou como não se tornar mais um idiota)

1. Ser bitolado, e limitar-se aos comandos, e não enxergar o algoritmo, a matemática, ao idioma e a história como outros recursos valiosos para programar.
2. Achar que jogar memória resolve sempre o problema
3. Tomar como premissa que algo é fixo e que jamais irá mudar.
4. Não ter metodologia científica, e apenas adotar as soluções que funcionaram anteriormente, sem questionar a validade das mesmas

Mas a principal, sem dúvida, é não compreender o papel da abstração

Posso acrescentar:

Achar que só precisa saber o básico do básico.
O cara aprendeu a usar int e String, a escrever “public static void main(String[] args)” e sabe usar o if, o for e o while. Daí já acha que pode programar qualquer coisa e que já sabe tudo que deveria sobre a linguagem. Pior ainda, quando vê alguém usando algo mais avançado, reclama com desprezo dizendo que não é para usar aquilo e que aquilo é complicar desnecessariamente.

Achar que pode reinventar uma roda quadrada melhor do que as que já foram inventadas.
Não preciso dizer mais nada, né?
Confesso que já cometi esse erro no passado (embora por desinformação eu tenha sido induzido a isto). Porém já estou curado dessa doença.

Se prender a uma ferramenta “bala de prata”.
Tem gente que só sabe usar um martelo, e pensa que tudo é prego. Quando pedem para o cara trocar uma lâmpada, ele a arranca na base da martelada, e então martela a lâmpada nova no soquete, e obviamente não apenas quebra a lâmpada nova como também o soquete. Depois sai dizendo por aí que a lâmpada era uma bosta.

Um caso que me dá nojo, combinação de vários (talvez todos) destes problemas em uma coisa só, e que eu tive a infelicidade de conhecer, é uma grande e famosa consultoria de três letrinhas que escraviza os clientes empurrando EJB 2 com java 1.4 e dizendo que EJB 3 é ruim, utilizando de dados inventados e estatísticas e testes manipulados para embasar este conceito. :shock: Como se não bastasse ainda têm VO/BO como religião. O cliente deles, que tem uma área de TI que é uma zona completa, têm como regra sagrada que devem utilizar um pacote fechado, congelado, e lacrado para todo o sempre como base para todos os sistemas, dentro dele são implementados a maioria dos “design patterns” listados aqui.

A famosa preguiça e a desinformação. Fora que na área de informática o cara programava PHP (nada contra a linguagem e os programadores, eu também programo em PHP) em casa e nunca se formou nem em Sistemas de Informação/Ciência da Computação, dai você fala para ele, não faz isso porque tu vai estourar a heap (exemplo idiota…), ai ele responde heap eh tua mae, aquela ¨%$¨(#%. O cara não sabe nem o que é heap, nem o que é OO e começa a programar, vai falar de design patterns então! Desculpa se alguém aqui ta nesse caso, mas eu comecei a programar com 13 anos (quase um coreano do Iphone ahhaha de 9anos…) e até eu entrar na faculdade eu era um açougueiro na programação.

Concordo plenamente com vocês, mas acho que a falta de materias de fácil acesso ainda é escasso, eu costumo recomendar o GUJ para amigos que acabam por adorar assim como eu, preguiça de pesquisar e ler são os maiores vilões, mas foi através de uma pesquisa que achei o GUJ e sempre tento sanar minha dúvida aqui, mas não deixo de pesquisar na Internet.
Mas acho que colaboração e uso de foruns como o GUJ dão uma força.

Abraço a todos.

Hum… eu jogo dinheiro que mais da metade de quem se forma nas faculdades hoje não sabem o que é design pattern ou, pelo menos, não fazem nem idéia de como aplicá-los. Aliás, a grande maioria mal consegue compreender conceitos de Orientação a Objetos e aplicá-los pra valer. Salvo raras exceções, as faculdades hoje em dia não estão com essa bola toda. Talvez nem seja o objetivo. Quem quer aperfeiçoar tem que ler, praticar e discutir com quem entende.

Em relação ao tópico, essa parte das ferramentas RAD pra mim é o pior. Me cansa ver o pessoal reclamando do Java porque não é que nem o Delphi nesse aspecto (e pra essas pessoas é só esse aspecto que conta).

kicolobo:

Olá a todos.
Em conversas com amigos, sempre discutimos quais seriam as principais “armadilhas” nas quais desenvolvedores caem, ou seja, aquelas situações nas quais um indivíduo se mete e acaba saindo um completo idiota sem cura (no que diz respeito a desenvolvimento).

Vemos isto todos os dias: um sujeito começa a “programar”, trilha pelo caminho que considera ser o mais fácil e, no final das contas, nunca mais consegue evoluir na profissão.

Acabei chegando à conclusão de que 6 são as principais armadilhas:

1. Determinismo linguístico: o sujeito que só utiliza um ambiente/linguagem de programação o tempo inteiro, ignorando completamente o resto do mundo
2. Software = banco de dados relacional: o sujeito que acredita que desenvolvimento de software se resuma à construção de bancos de dados
3. Ambientes de desenvolvimento RAD: o abuso no uso dos mesmos (é uma especialização da armadilha 1, porém com o problema de criar a ilusão de que desenvolvimento é uma tarefa simples)
4. Só saber português, ignorando completamente o inglês
5. Preguiça de ler
6. Medo da mudança

O que vocês acham? Quais são na opinião de vocês as principais armadilhas?

Eu detalhei melhor estas armadilhas no me blog, em : http://www.itexto.net/devkico/?p=292

Muito boa. Se resume ao “paga pau” de linguagem de programação. Aquele profissional, que se você disser que determinada linguagem não serve a determinado tipo de projeto, te declara guerra santa.

Na realidade, eu acho que é tudo fruto do que eu costumo chamar de “ascenção do usuário avançado”.
Trata-se daquela situação bem conhecida por nós que trabalhamos com desenvolvimento de sistemas: o sujeito sabe usar bem o computador, e em seguida, resolve que seu negócio é programar.
Então, começa por algo como as macros do Office, vai progredindo e tal, até escolher alguma linguagem que considere ser mais fácil de se trabalhar (normalmente, em 99% das vezes, consiste em um ambiente RAD).

Como não possui base teórica alguma pra trabalhar (concordo que faculdade não te prepara para o mercado de trabalho, no entanto, é fato que ela te ensina AO MENOS aonde buscar informações), se liga com unhas e dentes àquela linguagem, e a defende com tudo o que pode. Afinal de contas, o sujeito está inseguro! E agora que começou a programar e fazer alguns trocados, não vai querer ver o seu ganha pão ir por água abaixo.

E, como consegue algum sucesso nesta empreitada (pelo menos uns dois reais), acaba influenciando outras pessoas, que passam a seguir o mesmo caminho. Resultado: uma legião de “usuários avançados” que acham que são desenvolvedores e começam a “prestar serviços” por ai.

Além das armadilhas que já foram mencionadas, gostaria de adicionar estas:

1. Não saber ler coisas escritas no idioma português / inglês.
   . Ler não quer dizer que entendeu alguma coisa.

2. Não saber ouvir.
   .Considero esta uma das maiores armadilhas já construiadas por nós.

3. Não saber falar.
   .Muitos não conseguem se expressar.

4. Acreditar que os únicos que entendem de sistemas são os que trabalham com computadores.
   .Vc ficaria surpreso em saber o quanto um biólogo sabe sobre sistemas.

5. Pensar que a idéia de sistemas tem origem nos computadores.
   .Uma variação da 4.

6. Ignorar o ciclo de vida das coisas (todas as coisas sem exceção alguma).

7. Achar que construir coisas adaptaveis e flexiveis não vale a pena.

…

flws

kicoloco:

Na realidade, eu acho que é tudo fruto do que eu costumo chamar de “ascenção do usuário avançado”.
Trata-se daquela situação bem conhecida por nós que trabalhamos com desenvolvimento de sistemas: o sujeito sabe usar bem o computador, e em seguida, resolve que seu negócio é programar.
Então, começa por algo como as macros do Office, vai progredindo e tal, até escolher alguma linguagem que considere ser mais fácil de se trabalhar (normalmente, em 99% das vezes, consiste em um ambiente RAD).

Como não possui base teórica alguma pra trabalhar (concordo que faculdade não te prepara para o mercado de trabalho, no entanto, é fato que ela te ensina AO MENOS aonde buscar informações), se liga com unhas e dentes àquela linguagem, e a defende com tudo o que pode. Afinal de contas, o sujeito está inseguro! E agora que começou a programar e fazer alguns trocados, não vai querer ver o seu ganha pão ir por água abaixo.

E, como consegue algum sucesso nesta empreitada (pelo menos uns dois reais), acaba influenciando outras pessoas, que passam a seguir o mesmo caminho. Resultado: uma legião de “usuários avançados” que acham que são desenvolvedores e começam a “prestar serviços” por ai.

De acordo…

Conheço um pessoa que está terminando o mestrado, ministra aulas em faculdade e não sabe sobre padrões de projetos e vários outros aspectos relacionados a arquitetura.
Não estou dizendo que o cara tem que ser genio no assunto; mas sim, saber ao menos do que se trata, afinal ele está ministrando aulas em uma faculdade.

:shock:

flws

fantomas:

kicoloco:

Na realidade, eu acho que é tudo fruto do que eu costumo chamar de “ascenção do usuário avançado”.
Trata-se daquela situação bem conhecida por nós que trabalhamos com desenvolvimento de sistemas: o sujeito sabe usar bem o computador, e em seguida, resolve que seu negócio é programar.
Então, começa por algo como as macros do Office, vai progredindo e tal, até escolher alguma linguagem que considere ser mais fácil de se trabalhar (normalmente, em 99% das vezes, consiste em um ambiente RAD).

Como não possui base teórica alguma pra trabalhar (concordo que faculdade não te prepara para o mercado de trabalho, no entanto, é fato que ela te ensina AO MENOS aonde buscar informações), se liga com unhas e dentes àquela linguagem, e a defende com tudo o que pode. Afinal de contas, o sujeito está inseguro! E agora que começou a programar e fazer alguns trocados, não vai querer ver o seu ganha pão ir por água abaixo.

E, como consegue algum sucesso nesta empreitada (pelo menos uns dois reais), acaba influenciando outras pessoas, que passam a seguir o mesmo caminho. Resultado: uma legião de “usuários avançados” que acham que são desenvolvedores e começam a “prestar serviços” por ai.

De acordo…

Conheço um pessoa que está terminando o mestrado, ministra aulas em faculdade e não sabe sobre padrões de projetos e vários outros aspectos relacionados a arquitetura.
Não estou dizendo que o cara tem que ser genio no assunto; mas sim, saber ao menos do que se trata, afinal ele está ministrando aulas em uma faculdade.

:shock:

flws

Isso ocorre por dois motivos:

1. Padrões de projeto são uma coisa nova. Surgiram na década de 1990 e só ganharam força depois de 2000. A maior parte do que existe nas faculdades vem de conceitos teóricos desenvolvidos nas décadas de 1960, 1970 e 1980. E mesmo hoje, eu ainda não considero este tema como algo maduro, na minha visão isto está apenas começando.

2. Padrões de projeto infelizmente ainda não tem uma aceitação ampla. Para o pessoal que está avançado no java ele tem uma aceitação grande, mas para o pessoal que está em outras linguagens ou não está muito avançado no java, a penetração ainda é pequena. Muitos dos caras que dão aula de faculdade vieram do C, C++, Assembly, Perl, Pascal, PROLOG e Fortran. Só os mais novos que vieram do java, e boa parte destes não se tornaram maduros o suficiente para absorver padrões de projeto.

Eu mesmo, só fui ouvir falar de padrões de projeto pela primeira vez depois de formado, e atualmente só consigo compreender alguns deles. Ainda tenho que amadurecer neste sentido.

victorwss:

1. Padrões de projeto são uma coisa nova. Surgiram na década de 1990 e só ganharam força depois de 2000. A maior parte do que existe nas faculdades vem de conceitos teóricos desenvolvidos nas décadas de 1960, 1970 e 1980. E mesmo hoje, eu ainda não considero este tema como algo maduro, na minha visão isto está apenas começando.

Na verdade a idéia de padrões de projeto já vem da arquitetura desde a década de 70 também. Na década de 80 é que começaram a empregá-los em desenvolvimento de software. A popularidade creio que começou a vir na década de 90 com o livro do GoF que era exemplificado em C++.

Em relação ao tópico, o que mais me impressiona é a mediocridade, achar que já sabe o suficiente.

Se a pessoa vai seguir carreira acadêmica, dificilmente vai se interessar por p. projetos. O objetivo desse profissional é algoritmos e aplicações. Carreira Científica. (sem desmerecer os padrões, que realmente deixa o código legível, e resolve muitos problemas de OO).

Rafael Nunes:

victorwss:

1. Padrões de projeto são uma coisa nova. Surgiram na década de 1990 e só ganharam força depois de 2000. A maior parte do que existe nas faculdades vem de conceitos teóricos desenvolvidos nas décadas de 1960, 1970 e 1980. E mesmo hoje, eu ainda não considero este tema como algo maduro, na minha visão isto está apenas começando.

Na verdade a idéia de padrões de projeto já vem da arquitetura desde a década de 70 também. Na década de 80 é que começaram a empregá-los em desenvolvimento de software. A popularidade creio que começou a vir na década de 90 com o livro do GoF que era exemplificado em C++.

Em relação ao tópico, o que mais me impressiona é a mediocridade, achar que já sabe o suficiente.

Na verdade antes do GoF havia alguns conceitos informais sobre padrões de projeto, isso ainda engatinhava. O GoF é o que divide isso em pré-história e história.
Os exemplos deles também eram em smalltalk, além de C++.

Hum… eu jogo dinheiro que mais da metade de quem se forma nas faculdades hoje não sabem o que é design pattern ou, pelo menos, não fazem nem idéia de como aplicá-los. Aliás, a grande maioria mal consegue compreender conceitos de Orientação a Objetos e aplicá-los pra valer. Salvo raras exceções, as faculdades hoje em dia não estão com essa bola toda. Talvez nem seja o objetivo. Quem quer aperfeiçoar tem que ler, praticar e discutir com quem entende.

Em relação ao tópico, essa parte das ferramentas RAD pra mim é o pior. Me cansa ver o pessoal reclamando do Java porque não é que nem o Delphi nesse aspecto (e pra essas pessoas é só esse aspecto que conta).

concordo com vc…e num é só design patterns ñ…mta coisa, mtas vezes até basica o cara sai da faculdade sem saber…to no ultimo ano de CCP e tem cara na minha sala que num sabe nem oq é herança e polimorfismo…

OBS: Mto bacana o tópico!!

Tem uma coisa que eu não suporto: pessoas falando do que não sabem.
Só porque leu um artigo em tal blog/fórum/whatever falando mal(ou bem) sobre X tecnologia(.NET, Java, Python) o cara chega no trabalho falando sobre aquilo como se fosse o dono da razão, conhecesse plenamente a tecnologia e como se tivesse a capacidade de comparar com outra(geralmente a que está sendo usada atualmente por ele no trabalho). Ou senão porque leu um artigo técnico sobre alguma coisa chega cheio de buzzwords querendo mostrar que sabe alguma coisa quando tem somente um conhecimento muito superficial sobre o assunto.

Gabriel:

Tem uma coisa que eu não suporto: pessoas falando do que não sabem.
Só porque leu um artigo em tal blog/fórum/whatever falando mal(ou bem) sobre X tecnologia(.NET, Java, Python) o cara chega no trabalho falando sobre aquilo como se fosse o dono da razão, conhecesse plenamente a tecnologia e como se tivesse a capacidade de comparar com outra(geralmente a que está sendo usada atualmente por ele no trabalho). Ou senão porque leu um artigo técnico sobre alguma coisa chega cheio de buzzwords querendo mostrar que sabe alguma coisa quando tem somente um conhecimento muito superficial sobre o assunto.

Já vi inúmeras vezes este tipo de situação: normalmente para se vender alguma coisa.
E é basicamente assim: o sujeito chega dizendo que o produto X é maravilhoso, e que saiu na Info(!!!) ou qualquer outra revista dizendo hiper bem do produto.
Em seguida, dando uma olhada na revista, além da matéria, vê-se também um puta anúncio da empresa que produz o serviço.

Isto quando não fazem algo MUITO pior: pra te vendar alguma coisa (por exemplo, um Oracle da vida), te apresentam o próprio site do fabricante comparando o seu produto com os demais.
Chega a ser cômico

kicolobo:

Gabriel:

Tem uma coisa que eu não suporto: pessoas falando do que não sabem.
Só porque leu um artigo em tal blog/fórum/whatever falando mal(ou bem) sobre X tecnologia(.NET, Java, Python) o cara chega no trabalho falando sobre aquilo como se fosse o dono da razão, conhecesse plenamente a tecnologia e como se tivesse a capacidade de comparar com outra(geralmente a que está sendo usada atualmente por ele no trabalho). Ou senão porque leu um artigo técnico sobre alguma coisa chega cheio de buzzwords querendo mostrar que sabe alguma coisa quando tem somente um conhecimento muito superficial sobre o assunto.

Já vi inúmeras vezes este tipo de situação: normalmente para se vender alguma coisa.
E é basicamente assim: o sujeito chega dizendo que o produto X é maravilhoso, e que saiu na Info(!!!) ou qualquer outra revista dizendo hiper bem do produto.
Em seguida, dando uma olhada na revista, além da matéria, vê-se também um puta anúncio da empresa que produz o serviço.

Isto quando não fazem algo MUITO pior: pra te vendar alguma coisa (por exemplo, um Oracle da vida), te apresentam o próprio site do fabricante comparando o seu produto com os demais.
Chega a ser cômico :)

Isso me lembrou um caso bem conhecido por nós, de uma certa empresa baiana que vende um produto que eles dizem ser a maior maravilha que já foi inventada… :roll:

victorwss:

kicolobo:

Gabriel:

Tem uma coisa que eu não suporto: pessoas falando do que não sabem.
Só porque leu um artigo em tal blog/fórum/whatever falando mal(ou bem) sobre X tecnologia(.NET, Java, Python) o cara chega no trabalho falando sobre aquilo como se fosse o dono da razão, conhecesse plenamente a tecnologia e como se tivesse a capacidade de comparar com outra(geralmente a que está sendo usada atualmente por ele no trabalho). Ou senão porque leu um artigo técnico sobre alguma coisa chega cheio de buzzwords querendo mostrar que sabe alguma coisa quando tem somente um conhecimento muito superficial sobre o assunto.

Já vi inúmeras vezes este tipo de situação: normalmente para se vender alguma coisa.
E é basicamente assim: o sujeito chega dizendo que o produto X é maravilhoso, e que saiu na Info(!!!) ou qualquer outra revista dizendo hiper bem do produto.
Em seguida, dando uma olhada na revista, além da matéria, vê-se também um puta anúncio da empresa que produz o serviço.

Isto quando não fazem algo MUITO pior: pra te vendar alguma coisa (por exemplo, um Oracle da vida), te apresentam o próprio site do fabricante comparando o seu produto com os demais.
Chega a ser cômico :)

Isso me lembrou um caso bem conhecido por nós, de uma certa empresa baiana que vende um produto que eles dizem ser a maior maravilha que já foi inventada… :roll:

kkkkk…os posts sobre essa “empresa” são mto comédia…bem lembrado… :lol:

victorwss:

kicolobo:

Gabriel:

Tem uma coisa que eu não suporto: pessoas falando do que não sabem.
Só porque leu um artigo em tal blog/fórum/whatever falando mal(ou bem) sobre X tecnologia(.NET, Java, Python) o cara chega no trabalho falando sobre aquilo como se fosse o dono da razão, conhecesse plenamente a tecnologia e como se tivesse a capacidade de comparar com outra(geralmente a que está sendo usada atualmente por ele no trabalho). Ou senão porque leu um artigo técnico sobre alguma coisa chega cheio de buzzwords querendo mostrar que sabe alguma coisa quando tem somente um conhecimento muito superficial sobre o assunto.

Já vi inúmeras vezes este tipo de situação: normalmente para se vender alguma coisa.
E é basicamente assim: o sujeito chega dizendo que o produto X é maravilhoso, e que saiu na Info(!!!) ou qualquer outra revista dizendo hiper bem do produto.
Em seguida, dando uma olhada na revista, além da matéria, vê-se também um puta anúncio da empresa que produz o serviço.

Isto quando não fazem algo MUITO pior: pra te vendar alguma coisa (por exemplo, um Oracle da vida), te apresentam o próprio site do fabricante comparando o seu produto com os demais.
Chega a ser cômico :)

Isso me lembrou um caso bem conhecido por nós, de uma certa empresa baiana que vende um produto que eles dizem ser a maior maravilha que já foi inventada… :roll:

Seria um tal de J “jota” de uma tal “Companhia” :roll:

Pra mim sao:

• Arrogancia: Ja trabalhei e vejo por ai muita gente que se acha a ultima bolacha do pacote, que sabe tudo sobre tudo e nao eh bem assim, tem sempre coisas pra aprender.

• Impaciencia: Area de informatica eh uma das areas mais frustrantes que existe, eh mais frustante que ejaculacao precoce ou impotencia hehehe, entao acho que quem nao tem paciencia pra desempenhar as tarefas que aparecem no dia a dia nao serve pra trabalhar com informatica.

• Falta de iniciativa: Pessoas que nao tem iniciativa pra aprender algo novo, pra desenvolver pessoalmente e profissionalmente e ate mesmo aqueles que diante de um pequeno problema ja sai chorando e pedindo ajuda pros colegas de trabalhar a cada 10 segundos e pedindo ajuda em todos os forums da net sem ao menos tentar.

Pra mim esses sao os principais.

//Daniel

Nao, não é. Essa daí é mineira, não baiana. Se bem que tem características semelhantes.
Eu me referia a uma empresa que cria uma ferramenta de desenvolvimento baseada em fluxograma.

Não não, mas essa aí foi a motivação pra empresa baiana contratar 1500 analistas de sistemas pra desenvolver um produto que aumenta o e-pennis do programador em 25cm.

a

Design Patterns são um sintoma de linguagem deficiente. Uma boa linguagem de programação oferece os meios para expressar tudo o que for necessário sem precisar copiar e colar.

Desenvolvedores que não admitem não saber é um erro fatal. Não é pecado não saber. Melhor que fazer errado e funcionando de qualquer jeito por não querer admitir uma deficiência de conhecimento (não custa perguntar ou ter acompanhamento de um mais experiente). A área de informática tem muito disso, em se tratando de desenvolvimento então, a arrogância impera.

Uai: desde quando design patterns = copiar e colar?

Sem falar que ninguém é obrigado a usar. Patterns facilita e resolve muitos problemas.

Esse manja.

Rapaz, que tristeza. A POSCOMP deve ser obrogatória. Só assim vai regularizar a Computação.

Concordo em parte. Alguns patterns sim, mas não todos.

Concordo.

Mas se você quiser dizer que Design Patterns = copiar e colar, então, falou besteira.

“victorwss”:

Thiagosc wrote:
Design Patterns são um sintoma de linguagem deficiente.

Concordo em parte. Alguns patterns sim, mas não todos.

Thiagosc wrote:
Uma boa linguagem de programação oferece os meios para expressar tudo o que for necessário sem precisar copiar e colar.

Concordo.

Mas se você quiser dizer que Design Patterns = copiar e colar, então, falou besteira.

Se formos ver, no final das contas os patterns nada mais são do que bom uso da orientação a objetos documentados. Ninguém precisa seguir a risca a nomenclatura, nem precisa de bibliotecas externas, o que precisamos é só de uma linguagem que tenha características da orientação a objeto. Por isso acho meio estranho dizer que os patterns são sintoma de uma “linguagem deficiente”, já que eles não te obrigam a usar nenhum recurso fora da linguagem, só descrevem uma maneira mais interessante de usá-la.

Voltando ao foco do post, uma coisa muito marcante nos “profissonais” de TI é o tamanho do ego. É incrível o que a gente ouve, coisas como: “Essa bosta não funciona” (porque o cara não sabe usar) ou “Essa tecnologia XYZ é a melhor que existe” (só porque ele usa e não sabe nenhuma outra) são muito comuns. É claro que também só pelo fato de estar na área, ele já se sinta um deus e toda e qualquer outra área não tem a mínima importância… se acha bem “moderninho” só porque usa Ruby, por exemplo, ou acha que é arquiteto porque sabe fazer um Singleton. Tomara que um dia isso melhore

Link_pg:

Voltando ao foco do post, uma coisa muito marcante nos “profissonais” de TI é o tamanho do ego. É incrível o que a gente ouve, coisas como: “Essa bosta não funciona” (porque o cara não sabe usar) ou “Essa tecnologia XYZ é a melhor que existe” (só porque ele usa e não sabe nenhuma outra) são muito comuns. É claro que também só pelo fato de estar na área, ele já se sinta um deus e toda e qualquer outra área não tem a mínima importância… se acha bem “moderninho” só porque usa Ruby, por exemplo, ou acha que é arquiteto porque sabe fazer um Singleton. Tomara que um dia isso melhore :(

Na realidade, a situação é um pouquinho pior. Não é o cara que se acha um deus. Normalmente são os seus clientes que acham.
Depois quebram a cara e queimam TODA UMA CLASSE por causa de UM UNICO sujeito.

“kicolobo”:

Na realidade, a situação é um pouquinho pior. Não é o cara que se acha um deus. Normalmente são os seus clientes que acham.
Depois quebram a cara e queimam TODA UMA CLASSE por causa de UM UNICO sujeito.

Concerteza… e o que também contribui é o Gerente/Gestor/Vendedor que vende sua equipe como sendo formada por “deuses” :lol:
Aquele caso muito conhecido da “confiança” do tal gerente em sua equipe (1 ano? que nada a gente faz em 3 meses!)

victorwss:

Concordo.

Mas se você quiser dizer que Design Patterns = copiar e colar, então, falou besteira.

Pois deveriam ser, pq ainda que nao estejam embutidos na linguagem ainda lhe restam serem reutilizaveis.

É código repetido. O programador precisa digitar as mesmas coisas sempre e não há forma de abstrair essa repetição.

A orientação a objetos do Java é bem simplória, portanto tais usos são específicos para as limitações da linguagem. Além do mais, não é necessário OO para se escrever bom código. OO é muito supervalorizado.

Uai: desde quando design patterns = copiar e colar?

É repetir código feito macaquinho digitador, por isso que se chamam “patterns”.

Uai: desde quando design patterns = copiar e colar?

É repetir código feito macaquinho digitador, por isso que se chamam “patterns”.

Antes:Iterator it = colecao.iterator(); while (it.hasNext()) { Elemento e = (Elemento) it.next(); e.fazerAlgumaCoisa(); }Depois:for (Elemento e : colecao) { e.fazerAlgumaCoisa(); }Aqui, com uma evolução da linguagem o padrão Iterator passou a fazer parte do java de uma forma mais íntima. Mas mesmo assim continua lá. Suponhamos que java vá ter closures (não lembro a sintaxe BGGA, então vou inventar):colecao.each() : e { e.fazerAlgumaCoisa(); }Mesmo assim o pattern está lá.

O mesmo vale para o strategy, é uma forma de trabalhar com closure. Mas o negócio do design pattern não é a forma como você trabalha na linguagem, e sim a ideia por trás dele. No caso, a ideia do Iterator é ter um objeto que trás um a um os elementos da coleção que você itera. A ideia do strategy é fornecer um objeto que corresponda a parte mutável e específica do comportamento de um outro objeto. A forma como isso é codificado é a implementação do padrão, e não o próprio padrão.
É claro, que a linguagem pode favorecer os padrões e deixá-los bem mais suaves e naturais de serem implementados. Mas isso não os torna desnecessários e nem faz com que deixem de existir na linguagem.

E com base nisso, eu repenso aquela afirmação em que disse que concordo em parte com aquilo que tu afirmaste. Pensando bem, eu discordo.

Além disso, sempre surgem e são criados novos padrões, muitos deles bem específicos a certos domínios (ex: DAO), o que significa que nunca teremos uma linguagem que possa incorporar de forma satisfatória todos os padrões que surgirem.

1 - Acha que programar da dinheiro.
2 - Acha que ainda vai ser um programador aos 50 anos e vai viver disso.
3 - Priorizar a informatica, deixando sua vida pessoal de lado.
4 - Excesso de confiança, falta de testes.

victorwss:

O mesmo vale para o strategy, é uma forma de trabalhar com closure. Mas o negócio do design pattern não é a forma como você trabalha na linguagem, e sim a ideia por trás dele. No caso, a ideia do Iterator é ter um objeto que trás um a um os elementos da coleção que você itera. A ideia do strategy é fornecer um objeto que corresponda a parte mutável e específica do comportamento de um outro objeto. A forma como isso é codificado é a implementação do padrão, e não o próprio padrão.
É claro, que a linguagem pode favorecer os padrões e deixá-los bem mais suaves e naturais de serem implementados. Mas isso não os torna desnecessários e nem faz com que deixem de existir na linguagem.

E com base nisso, eu repenso aquela afirmação em que disse que concordo em parte com aquilo que tu afirmaste. Pensando bem, eu discordo.

Além disso, sempre surgem e são criados novos padrões, muitos deles bem específicos a certos domínios (ex: DAO), o que significa que nunca teremos uma linguagem que possa incorporar de forma satisfatória todos os padrões que surgirem.

Uma linguagem decente permitiria que você escrevesse código que gerasse código, i.e., metaprogramação. Assim tais “patterns” não existiriam pois estariam encapsulados em outra lógica e seriam expandidos no tempo correto para então serem executados. Logo não há dependência de keywords específicos ou da boa vontade de alguém implementar isso na linguagem pois você está no controle o tempo todo.

A própria necessidade de patterns é evidência que Java é uma linguagem deficiente.

Mas a partir do momento que você tem tal liberdade a forma de programar muda um pouco. Pensar em patterns é pensar de forma top-down, que é forma mais fácil de se trabalhar com linguagens como Java (o mesmo se aplica a C++, C#, etc). A habilidade de gerar código lhe permitiria abstrair toda repetição ao mesmo tempo em que desenvolve, logo uma abordagem iterativa e bottom-up é mais natural. Nesse caso as suas patterns sequer existiriam, pois você programador já teria eliminado os casos repetitivos gradualmente conforme você vai finalizando o código tornando-o não apenas mais legível, mas também mais otimizado.

Você acha abominações como o Hibernate ou o Spring ou Java EE existiriam se tivéssemos metaprogramação em Java, mais especificamente a habilidade de escrever código que gera outro código para então ser executado? Não estou me referindo a classes abertas ou a habilidade de mudar os métodos de uma classe em tempo de execução.

Já conheci caras com + de 50 que programavam, e muito bem diga-se de passagem; se não me engano vi alguns na CPM.

flws

No meu caso, ja cai em quase todas essas armadilhas, mas nunca cai na de sempre usar uma linguagem ou a de ignorar o q gente mais experiente diz. Tenho um amigo q ta sempre 2 passos a minha frente e ele sempre me da dicas boas do q estudar. Estou no ultimo ano de Ciên. da Computação na UEMS(Universidade Estadual de Mato Grosso do Sul) e sou me acho novato na programação.

-> Umas das coisas que eu comentei hoje, enquanto falava sobre JQuerry, era que “quanto mais você estuda, mais aparece pra estudar”.

Acham que isso ta certo ou acham q uma hora acaba?

Boa noite. Cara, acho que isso não é uma closure, é apenas um iterador que recebe um bloco de código. A closure precisaria preservar o contexo no qual foi instanciada e, até onde eu entendi, isso não foi feito! Posso estar errado.

Abraço.

Ex: Luca

wagnerfrancisco:

Boa noite. Cara, acho que isso não é uma closure, é apenas um iterador que recebe um bloco de código. A closure precisaria preservar o contexo no qual foi instanciada e, até onde eu entendi, isso não foi feito! Posso estar errado.

Abraço.

Neste caso o contexto se refere a posicao na colecao que se encontra o iterator.

cmoscoso:

wagnerfrancisco:

Boa noite. Cara, acho que isso não é uma closure, é apenas um iterador que recebe um bloco de código. A closure precisaria preservar o contexo no qual foi instanciada e, até onde eu entendi, isso não foi feito! Posso estar errado.

Abraço.

Neste caso o contexto se refere a posicao na colecao que se encontra o iterator.

Bom, não sei quanto ao exemplo ou sobre a implementação de closures em Java, mas closures mantém uma referencia ao ambiente léxico, ou seja, que é acessível quando de sua criação. Todas as variáveis léxicas que eram acessíveis quando o closure foi criado continuam existindo.

Thiagosc:

cmoscoso:

wagnerfrancisco:

Boa noite. Cara, acho que isso não é uma closure, é apenas um iterador que recebe um bloco de código. A closure precisaria preservar o contexo no qual foi instanciada e, até onde eu entendi, isso não foi feito! Posso estar errado.

Abraço.

Neste caso o contexto se refere a posicao na colecao que se encontra o iterator.

Bom, não sei quanto ao exemplo ou sobre a implementação de closures em Java, mas closures mantém uma referencia ao ambiente léxico, ou seja, que é acessível quando de sua criação. Todas as variáveis léxicas que eram acessíveis quando o closure foi criado continuam existindo.

Tem razao, acho que o contexto neste caso se refere ao proprio bloco de codigo (que manda fazerAlgumaCoisa() em cada item da colecao).

cmoscoso:

Thiagosc:

cmoscoso:

wagnerfrancisco:

Boa noite. Cara, acho que isso não é uma closure, é apenas um iterador que recebe um bloco de código. A closure precisaria preservar o contexo no qual foi instanciada e, até onde eu entendi, isso não foi feito! Posso estar errado.

Abraço.

Neste caso o contexto se refere a posicao na colecao que se encontra o iterator.

Bom, não sei quanto ao exemplo ou sobre a implementação de closures em Java, mas closures mantém uma referencia ao ambiente léxico, ou seja, que é acessível quando de sua criação. Todas as variáveis léxicas que eram acessíveis quando o closure foi criado continuam existindo.

Tem razao, acho que o contexto neste caso se refere ao proprio bloco de codigo (que manda fazerAlgumaCoisa() em cada item da colecao).

Pois é, eu cheguei a fazer um método que itera numa lista (simulando o each), mas não consegui enxergar closures explicitamente. Acho que uma closure seria algo assim (código em Ruby… não conheço essas closures que o Java terá):

var = 10
block = lambda do |x|
  puts x * var
end
[1,2,3].each(&block)

Aí a variável var, por exemplo, disponível quando o bloco foi criado está disponível em outros contextos.

Falou.

Wow! Nâo é incrível como uma discussão sobre ciladas profissionais acabou virando uma discussão sobre se design patterns são ou não um sintoma de falha na linguagem Java?

Sempre um querendo provar que sabe mais que o outro. tsc tsc tsc

windsofhell:

Sempre um querendo provar que sabe mais que o outro. tsc tsc tsc

Acho que acabamos de ver mais uma armadilha: um quer sempre saber mais que o outro… :lol:

Ha ha ha! Boa!

pura verdade…
o que mais vejo é sujeito “tentando” ficar rico programando…
uiahiaiahiahiah…

Com certeza…e realmente uma coisa que nem importa(usar ou não usar).

Com certeza…e realmente uma coisa que nem importa(usar ou não usar).

Design Patterns não importa usar? Por que?

wagnerfrancisco:

Pois é, eu cheguei a fazer um método que itera numa lista (simulando o each), mas não consegui enxergar closures explicitamente. Acho que uma closure seria algo assim (código em Ruby… não conheço essas closures que o Java terá):

var = 10
block = lambda do |x|
  puts x * var
end
[1,2,3].each(&block)

Aí a variável var, por exemplo, disponível quando o bloco foi criado está disponível em outros contextos.

Falou.

Se a closure e criada em runtime apenas quando ha alguma variavel a ser “enclausurada”, entao sim. Mas eu achei mesmo que o victorwss estava se referindo a uma eventual implementacao do padrao iterator usando closures, quando ela existisse na linguagem java.

Mias uma armadilha espelhada neste tópico, ir muito a fundo em uma linguagem e esquecer que nem sempre a solução é JAVA.

Não estou dizendo que não é bom conhecer algo a fundo, porém, depois que vc passa por algumas mudanças de mercado, como clipper > vb > java, as coisas começam a perder sua importancia como um todo.

Hoje em dia eu tento focar em coisas que serão aproveitadas a longo prazo, e não como eu estou economizando uma linha de código com a versão nova do iterator 8)

Exatamente.

aleck:

Hoje em dia eu tento focar em coisas que serão aproveitadas a longo prazo, e não como eu estou economizando uma linha de código com a versão nova do iterator 8)

O objetivo não era economizar linhas de código, e sim o “Don’t Repeat Yourself”, evitar aquele monte de código repetido e deixá-lo mais limpo.