[quote=giulianocosta]
Sinceramente não consigo te entender.[/quote]
Percebi que isso ia acontecer quando chamou de “tricks” se referindo aos recursos de metaprogramacao e DSLs do Ruby. 
[quote=sergiotaborda]
Você está claramente confundindo patterns com API. O que singifica que todo este tempo vc não sabia do que estava falando quando disse que patterns servem para compensar defeitos das linguagens. Linguagens não fazem nada. elas servem para criar quem faça. API padrão como a JSE são classes já criadas e testadas para diversos fins. A criação dessas classes é orientada a objetos e portanto deve seguir os mesmos padrões que qualquer outra classe seja de aplicação ou não. Padrões de Projeto são utilizados nessas API como em qualquer outra API. Nenhuma linguagem exporta para XML ou tem ORM sem ter uma API para isso. ActiveRecord do Ruby, embora utilize o nome e o conceito do padrão ActiveRecord é uma API , não é um design pattern que a linguagem tem. O que torna a API ActiveRecord do Ruby interessante é que ela usa o suporte a meta-class do ruby para adicionar métodos em runtime a qualquer classe. Isso tb pode ser feito em Java, apenas a implementação e a chamada no codigo será diferente porque a linguagem é diferente. Mas a API é a mesma e faz o mesmo.
Confundir a API ActiveRecord com o padrão ActiveRecord é um erro grosseiro. Se é isso que vem acontecendo neste e noutros topicos pelo pessoal que defende que patterns é defeito da linguagem e que java usa tantos patterns porque é imcompleta, bom, simplesmente vcs não sabem do que estão falando. Não a linguagem que usa padrões é a modelagem OO. E modelagem OO existe em qualquer linguagem OO. [/quote]
Não lembro de ter mencionado o termo API neste tópico. Nem mesmo ActiveRecord. Nem mesmo que um era a mesma coisa do outro, ou deixava de ser. Portanto ou voce respondeu pra pessoa errada, ou esta fazendo BDUF das minhas palavras.
Mas não vou te responder agora porque sinceramente não entendi aonde quer chegar. (juro que li 3x mas não entendi nada.)
Me diz qual outro termo eu poderia utilizar pra definir uma linguagem que o cara não precisa usar Design Patterns pra resolver certas situações?
O pensamento que tu vem espressando nos teus posts ao comparar uma linguagem de mais alto nível com uma de menor nível é que em Ruby os Patterns são coisas do Demo…
Um dia se criarem uma Linguagem com o nome de Chris Angel ou o David Copperfield e tu me fale que elas não precisam de DP, talvez eu dê o braço a torcer pra ti…heheheheheh
[quote=giulianocosta][quote=mochuara]
Percebi que isso ia acontecer quando chamou de “tricks” se referindo aos recursos de metaprogramacao e DSLs do Ruby.
[/quote]
Me diz qual outro termo eu poderia utilizar pra definir uma linguagem que o cara não precisa usar Design Patterns pra resolver certas situações?
O pensamento que tu vem espressando nos teus posts ao comparar uma linguagem de mais alto nível com uma de menor nível é que em Ruby os Patterns são coisas do Demo…
Um dia se criarem uma Linguagem com o nome de Chris Angel ou o David Copperfield e tu me fale que elas não precisam de DP, talvez eu dê o braço a torcer pra ti…heheheheheh[/quote]
O curioso é que quem trouxe Ruby pra discussão foi vc. E mais curioso ainda é alguém querer definir algo sem estar em condições pra isso.
[quote=mochuara][quote=giulianocosta][quote=mochuara]
Percebi que isso ia acontecer quando chamou de “tricks” se referindo aos recursos de metaprogramacao e DSLs do Ruby.
[/quote]
Me diz qual outro termo eu poderia utilizar pra definir uma linguagem que o cara não precisa usar Design Patterns pra resolver certas situações?
O pensamento que tu vem espressando nos teus posts ao comparar uma linguagem de mais alto nível com uma de menor nível é que em Ruby os Patterns são coisas do Demo…
Um dia se criarem uma Linguagem com o nome de Chris Angel ou o David Copperfield e tu me fale que elas não precisam de DP, talvez eu dê o braço a torcer pra ti…heheheheheh[/quote]
O curioso é que quem trouxe Ruby pra discussão foi vc. E mais curioso ainda é alguém querer definir algo sem estar em condições pra isso.[/quote]
E sobre design patterns? você sabe o que é e conhece alguns padrões?
To achando boa a discussão, mas eu não consegui entender ou achar nenhum exemplo em que o uso de um padrão seja defeito da linguagem, java por exemplo.
blz véio. Esqueçamos o nome “Ruby” da discussão (Nem vou voltar nos posts pra saber se fui eu ou não quem o referenciou primeiro). Vou assumir que fui eu quem o trouxe pra discussão. Me cite uma linguagem que o cara não precise se preocupar com DPs?
Aqui tu deixa claro que a linguagem que não absorve DPs é porque a linguagem não tem abstração necessária.
[quote=mochuara][quote=sergiotaborda]
Você está claramente confundindo patterns com API. [/quote]
[/quote]
Esse é o problema. Você não identifica isto que vc escreveu:
“Se ocasionalmente sua aplicação precisa persistir em banco de dados, expor uma interface web, exportar dados pra XML ou qualquer coisa que não faz parte do core da aplicação”
como responsabilidades de API e confunde com patterns.
O que significa que toda a sua argumentação é inválida porque se vc não sabe distinguir, vc não tem base para argumentar que pattern é uma deficiência da linguagem. vc simplesmente não sabe o que “pattern” significa.
[quote=sergiotaborda]
Esse é o problema. Você não identifica isto que vc escreveu:
“Se ocasionalmente sua aplicação precisa persistir em banco de dados, expor uma interface web, exportar dados pra XML ou qualquer coisa que não faz parte do core da aplicação”
como responsabilidades de API e confunde com patterns.
O que significa que toda a sua argumentação é inválida porque se vc não sabe distinguir, vc não tem base para argumentar que pattern é uma deficiência da linguagem. vc simplesmente não sabe o que “pattern” significa.[/quote]
Boa tarde,
Sérgio Taborda
O que percebo, é que muitos que estão discutindo sobre padrões não tem muita introdução no assunto, acredito que isso seja uma deficiência de literatura e de bons estudos.
Abraçoss
Bem, passei as últimas 2 horas lendo este tópico inteiro. No final já estava meio perdido porque isso é algo bem cansativo e difícil de ler.
Mas, tenho algo a acrescentar. Citando um texto que vi certa vez em algum lugar por aí, mas não lembro uem era o autor. Não lembro exatamente como ele era versado, mas era algo assim:
Algo que acho que serve mais ou menos como um exemplo: Imagine na década de 1950, onde ninguém nem sequer sonhava com qualquer coisa semelhante aos design patterns de hoje. Naquela época, o simples fato de separar hardware de software e de utilizar uma linguagem de montagem ao invés de utilizar-se a linguagem de máquina diretamente já eram os design patterns daquela época. Hoje em dia isto está tão eternizado no coração de todos (ou quase todos) os sistemas e linguagens de programação que ninguém mais discute.
Um pouco mais adiante, surge conceitos como modularização e a utilização de estruturas de dados mais complexas do que registradores e variáveis. De certa forma, pode-se dizer que a ideia de organizar o código em funções, ao invés de um gigantesco macarrão cheio de gotos promíscuos é um design pattern primitivo. Hoje em dia, isto está eternizado no coração das linguagens de programação de tal forma que ninguém mais percebe que era um design pattern. Implementar funções utilizando linguagens de montagem que não tenham instruções específicas necessita de certo conhecimento de modelagem do programador. Nota-se que isto não é muito diferente do que vemos hoje: para modelar uma certa situação que não está no coração da linguagem, o programador precisará saber usar um design pattern (mesmo que sem perceber).
Aliás, quanto ao goto, ele é um caso interessante. Em linguagens de programação extremamente primitivas, não muito diferentes das linguagens de autômatos e/ou máquinas de Turing minimalistas, o goto chega a ser um padrão que simplifica bastante as coisas. No entanto, a medida que as linguagens foram evoluindo, pode-se dizer que ele deixou de ser um padrão e virou um anti-padrão. Na verdade ele continua lá, na modelagem interna de fors, whiles e até de chamadas de funções, mas ele não é mais visível no nível de abstração das linguagens atuais.
E mais adiante ainda, já no final da década de 1970 e início da década de 1980, surgem as linguagens OO. A OO por si só não passa de um monte de design patterns em linguagens estruturadas. Conceitos como encapsulamento e polimorfismo tornam-se design patterns. Isso daí é bem estranho, mas é verdade. Implementar OO em uma linguagem não-OO requer o uso de alguns truques e não é uma tarefa trivial. Se não for algo bem feito, o resultado é uma grande gambiarra que cria muito mais problemas do que resolve. Se for algo bem feito, o resultado é uma modelagem que a primeira vista é estranha e incomum, mas que na verdade é muito melhor do que aquela que normalmente se esperaria da linguagem. Não é exatamente isso que ocorre com os Design Patterns?
Os design patterns GoF eram o estado da arte na OO em 1994. Não se passou muito tempo desde então, foram apenas 15 anos. E hoje GoF são feijão-com-arroz. Não faço ideia de quais serão os design patterns quentes de 2030 ou de 2050, mas certamente lá, os GoF (pelo menos alguns deles) já serão algo tão trivialmente eternizados no coração das linguagens de programação da moda, de tal forma que ninguém mais os discutirá.
Olhando do futuro para o passado, implementar OO em uma linguagem não-OO já é algo difícil. Implementar OO em linguagens de baixo nível é algo que poucos sequer ousam fazer (só vi um caso sério até hoje). Implementar OO em linguagens minimalistas de máquinas de Turing deve ser algo bem interessante, mas certamente é muito difícil e desafiador. É aí que entra a complexidade inerente como efeito colateral dos design patterns. Design patterns adicionam complexidade inerente quando usados nas linguagens OO tradicionais de hoje. A OO em si acrescenta complexidade inerente quando usada em linguagens estruturadas. A estruturação acrescenta complexidade inerente quando utilizada em linguagens não-estruturadas. A manipulação de variáveis, comandos e instruções adiciona complexidade inerente em linguagens de baixo nível. O conceito de instruções e registradores adicionam complexidade inerente a máquinas de Turing. É aí que eu imagino como seria implementar o seu Design Pattern OO preferido em uma linguagem minimalista de máquina de Turing. Certamente, por mais simples que seja o pattern, o resultado teria uma complexidade tão grande que certamente teria a cara de ser uma gigantesca gambiarra, e usar algo mais simples acabaria sendo certamente muito melhor e mais fácil.
Penso que a mesma coisa pode acabar ocorrendo com os design patterns de hoje. Alguns tornar-se-ão características tão intrínsecas e enraizadas nas linguagens do futuro que muitas vezes nem serão percebidas como design patterns (Iterator, Strategy, Observer e MVC são bons candidatos). Outros podem se tornar anti-padrões, mesmo que sejam coisas simples com finalidades simples e que se usadas corretamente não machucam ninguém, tal como ocorreu com o goto e está ocorrendo hoje com o Singleton e com os BOLOVO.
Aliás, o motivo pelo qual sou contra Singletons, não é muito diferente do motivo pelo qual sou contra gotos. Não há nada de errado neles por si só. São simples e muito úteis quando bem usados. O problema é que é tão difícil e raro utilizá-los diretamente de forma correta e legítima que geralmente só de pensar em usá-los já costuma ser besteira.
Aliás, voltando ao assunto do Singleton, cita-se frequentemente de colocar-se a conexão com o banco de dados em um singleton. Eu fazia isso em um projeto que usava Oracle e tudo era lindo e maravilhoso, até que em um certo dia tive uma surpresa: Chegou um requisito novo que tinha que ser implementado que necessitava de haver uma conexão com um segundo banco de dados em MySQL. Aí foi um sufoco implementar isso, e o singleton teve que ser literalmente explodido. E haja refatoração!
Mais tarde, um colega cometeu o mesmo erro, havia umas variáveis lá que guardavam os dados do usuário conectado no cliente swing. O colega decidiu usar o singleton. Pouco tempo depois, o cliente pediu um requisito de troca do usuário, que permitia haver mais de um usuário logado na mesma máquina ao mesmo tempo. Foi outra cirurgia de refatoração a ser feita.
Mais tarde em outro projeto em outro lugar estava lá um singleton que mantinha a conexão com o banco, dentro de um JAR de terceiros. Minha intuição já me disse que aquilo ia dar em m****. E foi o que aconteceu: Depois de um tempo surgiu a necessidade de conectar em dois bancos de dados ao mesmo tempo. Nem lembro como foi que isso foi resolvido.
A minha conclusão é que o singleton é hoje o que o goto foi a 40 anos atrás.
Olá
Vitor, você escreveu demais, isto é, ficou até parecido no tamanho com uns e outros, mas o que escreveu faz sentido. Pelo menos para mim. E achei muito legal comparar o Singletons com GOTO, se bem que bater em Singleton é o mesmo que bater em cachorro morto.
Antigamente a gente também tinha nossos padrões. Só que não eram públicos. Faziam parte do que chamávamos de nossa caixa de ferramentas.
O fato dos padrões hoje serem públicos é que acarretou o abuso deles.
Continuo com a mesma velha opinião de que os padrões devem ser usados quando reconhecidos ao invés de usados como demonstração de que o programador conhece padrões como já fui testemunha em mais de um projeto. E pior era ver os caras descrevendo o código usando padrões para complicar a linguagem dentro de uma equipe em que nem todos visualizam os padrões do mesmo jeito que o cara falava.
[]s
Luca
Sempre haverá uma minimização dos esforço da solução, sem haver portanto anulação do padrão anteriormente existente. Um exemplo disto é a JSR 300 propõe uma saída para implementação do singleton utilizando @singleton como alvo de declaração em uma classe.
O mesmo vale para o padrão citado MVC, que trata-se de um padrão de arquitetura, e não um design pattern conforme victor citou, uma vez que, propõe esta disponibilidade em ditas camadas lógicas de sua aplicação, e conforme cita Craig Larman[2005] pág: 231
Os padrões de projeto têm sua importância, e ainda irão vingar por bom tempo, por resolver problemas de forma independente, e diante de suas desvantagem de forma agrupada com outros padrões, afim de minimizar estes problemas recorrentes.
Christopher Alexander em 1970 estabeleceu está proposta de padrões de projeto há quase 40 anos, e ainda assim eles continuam perssuadidos, mesmo que com certo esforço, visto que o contexto sempre tende a mudar.
Iterator, Strategy, Observer são padrões de projeto como proposta de soluções para problemas, ainda ditos recorrentes, mas que dependerá de como “quem” os está usando.
Não adianta somar problemas que um padrão não possa resolver, e a partir daí querer ditá-lo para o mundo todo depracated. O problema pode estar entre a cadeira e o teclado! 
[quote=faelcavalcanti]Sempre haverá uma minimização dos esforço da solução, sem haver portanto anulação do padrão anteriormente existente. Um exemplo disto é a JSR 300 propõe uma saída para implementação do singleton utilizando @singleton como alvo de declaração em uma classe.
O mesmo vale para o padrão citado MVC, que trata-se de um padrão de arquitetura, e não um design pattern conforme victor citou, uma vez que, propõe esta disponibilidade em ditas camadas lógicas de sua aplicação, e conforme cita Craig Larman[2005] pág: 231
Os padrões de projeto têm sua importância, e ainda irão vingar por bom tempo, por resolver problemas de forma independente, e diante de suas desvantagem de forma agrupada com outros padrões, afim de minimizar estes problemas recorrentes.
Christopher Alexander em 1970 estabeleceu está proposta de padrões de projeto há quase 40 anos, e ainda assim eles continuam perssuadidos, mesmo que com certo esforço, visto que o contexto sempre tende a mudar.
Iterator, Strategy, Observer são padrões de projeto como proposta de soluções para problemas, ainda ditos recorrentes, mas que dependerá de como “quem” os está usando.
Não adianta somar problemas que um padrão não possa resolver, e a partir daí querer ditá-lo para o mundo todo depracated. O problema pode estar entre a cadeira e o teclado! [/quote]
Bem, eu não quis me prender a terminologias quando equiparei coisas como Iterator, MVC, goto, polimorfismo, encapsulamento e criação de funções. O que eu quis mostrar aqui é o surgimento de técnicas de nível mais abstraído do que o que existe na linguagem em si. Talvez tenha sido falha minha, mas então ao invés de chamar estas coisas todas de design patterns vamos chamar de qualquer outra coisa que você queira.
E em momento nenhum eu quis dizer que Iterator, Strategy e Observer serão deprecated. Muito pelo contrário! Por exemplo, o for-each do java esconde que existe um Iterator por trás porque neste caso a linguagem absorveu o Iterator de forma natural (através de um syntatic sugar). Dependendo da linguagem e do ambiente, outras formas mais profundas de absorvê-los seriam possíveis que não apenas syntatic sugars. Por exemplo, instruções específicas da máquina virtual (ou até do hardware) poderiam ser criadas para implementar esses patterns sem que isso torne-se visível na lingaugem. Mas dizer que o Iterator é/foi/será absorvido pela linguagem é algo completamente diferente do que dizer que ele será deprecated.
Quanto ao Strategy, o uso de closures tende a ser um Strategy disfarçado.
Quanto ao Observer, imagine que em uma linguagem no futuro, seja possível adicionar algum tipo de listener diretamente no atributo independente do tipo que ele for sem precisar mantendo os objetos que representam os listeners em listas explícitas e disparando-os explicitamente. Neste caso, a linguagem terá absorvido o Observer.
Aliás, a própria ideia de usar um while é uma técnica recorrente (para não dizer padrão e usar uma terminologia inadequada) é o resultado de em linguagens não-estruturadas de utilizar-se desvios condicionais (if-goto) de forma que laços com escopo bem definido fossem criados. Em linguagens estruturadas isso tornou-se parte da própria linguagem.
Não obstante, agora olho para um dos próximos paradigmas que ainda está na infância: a programação orientada a aspectos. Conceitos de programação orientada a aspectos tais como injeção de dependências, interceptadores, eliminação de cross-cutting concerns entre outros são atualmente implementados de forma forçada, feia e um tanto limitadas nas linguagens OO. E não é difícil perceber-se que se as linguagens atuais suportassem isso nativamente, essas coisas ficariam muito mais fáceis e limpas de se fazer.
Aliás, anotações do java 5+ demonstram isso também. No java 1.4 e inferiores, as anotações eram simuladas por uma miríade de técnicas malucas e complicadas, tais como arquivos XML, geradores de código, herança de classes malucas de frameworks específicos entre outros meios. Bastou que a própria linguagem suportasse isso nativamente que a partir daí pode-se jogar fora toda ou quase toda essa parafernália inventada para simular um recurso que faltava na linguagem e que muitas vezes nem se notava que estava faltando. Como se não bastasse, a implementação nativa na linguagem é muito superior e muito mais simples do que as tentativas malucas que eram feitas para simulá-la.
Quanto ao MVC, não duvido que a próxima linguagem web da moda (moda que pode durar décadas inclusive) tenha construções de linguagens específicas para um design MVC, mas que estas construções sejam tão transparentes que muitas vezes o programador nem perceba que está usndo o MVC. Frameworks que tentam fazer isso artificialmente sem ser nativo da linguagem já temos aos montes, tal como foi o caso das anotações no java 5.
Além disso, isso não significa que todos os padrões vão ou ser condenados como o goto ou serem escondidos por construções da linguagem tal como o exemplo que dei do while. Muitas técnicas e padrões continuam as mesmas ao longo de décadas.
O fato de vc ter encontrado uma citação que tem as palavras “nivel de arquitura” e MVC no mesmo paragrafo não torna o MVC um padrão arquitetural. MVC não se dispoe a separar as coisas em camadas como vc citou - MVC é usado em apenas 1 camada - portanto, nunca poderá ser considerado padrão arquitetural. A confusão em considerá-lo padrão arquiterural é pensar os manipuladores de eventos, a IGU e os dados relacionados estão em camadas diferentes. Não estão.
O exemplo claro disto é o JavaFX. Se vc ja tiver uma aplicação swing corretamente desenvolvida, ou seja, com cliente, apresentação e as outras camadas separadas, então, vc pode modificar o cliente de swing para Fx no cliente sem retrabalho nas outras chamadas. afinal é isso que significa separação de camadas. Repare que o MVC está todo contido no proprio Fx e no Swing. Ele não vaza para a camada inferior que é a apresentação.
Porque o MVC está associado a controles fisicos como teclado e mouse, as pessoas assumem que é um padrão arqutietural, mas não é. Para ser um padrão arquitetural ele teria que interferir com plataformas, andares (que eu chamei camadas neste texto) , nodos ou protocolos de comunicação. Ele não interfere com nada disto, logo não é um padrão de arquitetura. Embora existam muitos desavisados que o chamam assim.
um padrão realmente de arquitetura é o Cluster, por exemplo.
[quote=victorwss]
Penso que a mesma coisa pode acabar ocorrendo com os design patterns de hoje. Alguns tornar-se-ão características tão intrínsecas e enraizadas nas linguagens do futuro que muitas vezes nem serão percebidas como design patterns (Iterator, Strategy, Observer e MVC são bons candidatos).[/quote]
Scala e Clojure que são linguagens bombando HOJE tem mecanismo de concorrencia enbutido na linguagem, Clojure vai além e conta ainda com controle transacional (UnitOfWork) e vc me diz que a linguagem do futuro vai conter Strategy e Observer?? :shock:
“O Design é sempre a intenção da Arquitetura”
Singletons ou não-singletons
Para o Spring, todos os beans são singletons, ou seja, só existe uma instância de cada um deles para aquela instância do framework.Algumas vezes, os nossos objetos têm dependências que não podem ser singletons, ou seja, cada bean precisa de uma instância própria de sua dependência.Para que o Spring trate um objeto não-singleton, o atributo “singleton” do nó<bean> deve estar com o valor “false”.
<bean id="dependencia" class="gerenciador.CursoDaoMemoria"singleton="false"/">
[quote=mochuara][quote=victorwss]
Penso que a mesma coisa pode acabar ocorrendo com os design patterns de hoje. Alguns tornar-se-ão características tão intrínsecas e enraizadas nas linguagens do futuro que muitas vezes nem serão percebidas como design patterns (Iterator, Strategy, Observer e MVC são bons candidatos).[/quote]
Scala e Clojure que são linguagens bombando HOJE tem mecanismo de concorrencia enbutido na linguagem, Clojure vai além e conta ainda com controle transacional (UnitOfWork) e vc me diz que a linguagem do futuro vai conter Strategy e Observer?? :shock: [/quote]
Releia o que eu escrevi.
O goto por exemplo, continua existindo firme, forte, frequente e feliz nas profundezas dos sistemas e das linguagens mais modernas de hoje em dia, mas ele está escondido debaixo de tantas camadas de abstração que você não o vê, não mais o utiliza diretamente, mas isto não significa que ele não exista. O mesmo está acontecendo com o Strategy, Observer e Iterator.
No javafx, é bem interessante como é que o Observer foi absorvido pela linguagem em si na forma de triggers. Clojure também é um exemplo interessante de como as linguagens estão evoluindo.
Mas, há uma grande diferença entre Strategy, Observer, Iterator e goto. O goto quando utilizado diretamente pelo prograador é em 99,9% dos casos algo extremamente ruim que vai trazer muitos mais problemas do que benefícios. O Strategy, Observer e Iterator nas linguagens mais tradicionais de hoje (Java, C++, C#, smalltalk) decididamente não são o mesmo caso. Em linguagens mais avançadas como Clojure, JavaFX e Scala, o uso direto deles começa a se tornar um anti-pattern, mas acho que ainda não ao ponto que o goto tinha se tornado. Por outro lado o Singleton, já sofreu tanta entropia que está em situação cada vez mais semelhante ao goto: usá-lo diretamente é em 98% dos casos um tiro no pé, mas isso não significa que ele deixará de existir ou tornar-se-á deprecated, nem mesmo com o goto isto ocorreu. O seu uso direto é que poderá se tornar cada vez mais deprecated.
Bem, estou inventando agora: Poderíamos chamar de entropia a característica que uma determinada técnica ou padrão de programação tem que a deixa cada vez menos vantajosa e mais problemática quando usada diretamente a medida que cresce o nível de abstração. O goto por exemplo tem uma entropia altíssima, é vantajoso apenas nas camadas mais inferiores e menos abstraídas de linguagem de montagem, linguagens de máquina e bytecodes. O Singleton também já sofreu bastante entropia e não é mais vantajoso nas linguagens de hoje. O Iterator, Observer, Strategy e MVC já tem alguma entropia significativa também, mas ainda estão longe do ponto aonde o Singleton e o goto chegaram.
Algumas técnicas que surgem tendem a ganhar entropia de forma bem lenta, como por exemplo a modularização do código em procedimentos e funções. Esta técnica, apesar de bem antiga sofreu pouca entropia, mas isto não significa que um dia, em um futuro distante isso não vá ocorrer.
Minha conclusão empírica é que cada linguagem tem os seus padrões e técnicas apropriadas e específicas para o seu nível de abstração. Usar técnicas de níveis de abstração inferiores ao da linguagem tende a trazer gambiarras, problemas e bad smells. Usar técnicas de níveis de abstração superiores ao da linguagem tende a trazer complexidade e verbosidade. Quanto maior a diferença entre o nível de abstração da técnica e da linguagem, pior fica este problema.
[quote=jhacker]“O Design é sempre a intenção da Arquitetura”
Singletons ou não-singletons
Para o Spring, todos os beans são singletons, ou seja, só existe uma instância de cada um deles para aquela instância do framework.Algumas vezes, os nossos objetos têm dependências que não podem ser singletons, ou seja, cada bean precisa de uma instância própria de sua dependência.Para que o Spring trate um objeto não-singleton, o atributo “singleton” do nó<bean> deve estar com o valor “false”.
<bean id="dependencia" class="gerenciador.CursoDaoMemoria"singleton="false"/">[/quote]
Isto já foi bastante discutido páginas atrás. É um erro de conceito. Embora sejam chamados erroneamente de singletons, não são singletons, são shared objects.
[quote=sergiotaborda]Porque o MVC está associado a controles fisicos como teclado e mouse, as pessoas assumem que é um padrão arqutietural, mas não é. Para ser um padrão arquitetural ele teria que interferir com plataformas, andares (que eu chamei camadas neste texto) , nodos ou protocolos de comunicação. Ele não interfere com nada disto, logo não é um padrão de arquitetura. Embora existam muitos desavisados que o chamam assim.
um padrão realmente de arquitetura é o Cluster, por exemplo.
[/quote]
você demonstrou um exemplo, não necessariamente, ele, se resume a isto! sempre tenho visto o modelo MVC como padrão arquiteturial, me mostre uma referência que o dita que não o seja, que eu me convencerei!
a citação que mencionei, expôe também as vertentes de como o padrão MVC surgiu mesmo que com propósito limitado na época.
acho que temos que esclarecer ao pessoal agora algumas perguntas como:
[quote]1. Qual conceito de um padrão arquiteturial ? (motivado por referências)
2. Como um padrão arquiteturial pode ser classificado ?[/quote]
entre outras perguntas interessantes que poderiamos incluir aqui, mas acho que isto pode ser melhor discutido em um novo tópico!
também concordo luca.
por exemplo, se você dispõe dos conceitos e princípios de O.O, você acaba usando um padrão sem saber. antigamente eu utilizava o template method sem saber.
a didática de aprender padrões de projeto, tratando-se de padrões da GoF ou GRASP neste caso, é justamente um ato de exercitar bons princípios de O.O, para velhos problemas conhecidos e que serão recorrentes ao longo da nossa atuação profissional, de forma que um determinado design descreva características de um ou mais padrões, resumindo-se em poucas palavras.
agora, se você souber fazer bom uso disto sem conhecer padrões e explicar como algo foi desenvolvido, você está no caminho mais do que certo, visto vez que, eles devem ser mencionados quando necessário, e isto é verdade porque nosso objetivo final é concluir um projeto atendendo a contento o mais simples possível de forma a minimizar custo, em prazo e que possibilite que a equipe se comunique em seu ritmo natural de forma a evoluir sem depender de padrões e catálogos como referências e normas em suas práticas atuais, e futuras pois podem acabar não sendo promissoras.
abusar do uso de padrões de projeto pode fazer mal a nossa saúde e a do projeto que estamos tratando!
também concordo luca.
por exemplo, se você dispõe dos conceitos e princípios de O.O, você acaba usando um padrão sem saber. antigamente eu utilizava o template method sem saber.
a didática de aprender padrões de projeto, tratando-se de padrões da GoF ou GRASP neste caso, é justamente um ato de exercitar bons princípios de O.O, para velhos problemas conhecidos e que serão recorrentes ao longo da nossa atuação profissional, de forma que um determinado design descreva características de um ou mais padrões, resumindo-se em poucas palavras.
agora, se você souber fazer bom uso disto sem conhecer padrões e explicar como algo foi desenvolvido, você está no caminho mais do que certo, visto vez que, eles devem ser mencionados quando necessário, e isto é verdade porque nosso objetivo final é concluir um projeto atendendo a contento o mais simples possível de forma a minimizar custo, em prazo e que possibilite que a equipe se comunique em seu ritmo natural de forma a evoluir sem depender de padrões e catálogos como referências e normas em suas práticas atuais, e futuras pois podem acabar não sendo promissoras.
abusar do uso de padrões de projeto pode fazer mal a nossa saúde e a do projeto que estamos tratando! [/quote]
Há uma sutil, mas gritante diferença entre saber como usar padrões de projeto e saber quando usar padrões de projeto.