Livro Design Patterns: e se houvesse uma segunda edição?

JavaBaby Membro desde: 02/05/2007 00:51:18 Mensagens: 77 Offline

sergiotaborda wrote:

mochuara wrote:

giulianocosta wrote:
Bom, vamos partir para exemplor práticos. Estou construindo um sistema contábil em Java atualmente e quero utilizar o conceito de Contas, Lançamentos, Estornos, Eventos, etc... (Account Pattern)
Me diz, a "API" ou "Mandinga" do Ruby que vai resolver os problemas que esse Pattern em questão me resolve?
Neste link(http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/ap/fin/intro.html) tem uma referência do Pattern que estou falando.

Como falei anteriormente, minha aplicacao deve refletir apenas o core da aplicacao. Não conheco sua aplicação nem o padrão mencionado, mas se este é identificado por vc mesmo como sendo o core não faz muito sentido em querer que a linguagem abstraia o core do seu próprio código.

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 não deveria usar patterns pra isto numa linguagem de alto nivel, extensivel.

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.

bem que parece mesmo que voces estavam falando sobre coisas diferentes...

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

giulianocosta wrote:
Sinceramente não consigo te entender.

Percebi que isso ia acontecer quando chamou de "tricks" se referindo aos recursos de metaprogramacao e DSLs do Ruby.

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

sergiotaborda wrote:
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.

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.)

JavaEvangelist Membro desde: 11/08/2003 09:59:28 Mensagens: 436 Offline

mochuara wrote:
Percebi que isso ia acontecer quando chamou de "tricks" se referindo aos recursos de metaprogramacao e DSLs do Ruby.

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

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

giulianocosta wrote:

mochuara wrote:
Percebi que isso ia acontecer quando chamou de "tricks" se referindo aos recursos de metaprogramacao e DSLs do Ruby.

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

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.

JavaBaby Membro desde: 02/05/2007 00:51:18 Mensagens: 77 Offline

mochuara wrote:

giulianocosta wrote:

mochuara wrote:
Percebi que isso ia acontecer quando chamou de "tricks" se referindo aos recursos de metaprogramacao e DSLs do Ruby.

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

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.

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.

JavaEvangelist Membro desde: 11/08/2003 09:59:28 Mensagens: 436 Offline

mochuara wrote:
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.

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?

mochuara wrote:
Se vc precisa lidar com patterns é sinal que sua linguagem falta abstrações necessarias (o que é muito comum no caso da linguagem Java). Ainda assim não acho que patterns sejam inuteis. Eles são uteis, no código da concorrência.

Aqui tu deixa claro que a linguagem que não absorve DPs é porque a linguagem não tem abstração necessária.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3420 Offline

mochuara wrote:

sergiotaborda wrote:
Você está claramente confundindo patterns com API.

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.

What is classpath? Membro desde: 05/11/2009 11:46:18 Mensagens: 8 Offline

sergiotaborda wrote:
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.

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

This message was edited 5 times. Last update was at 06/11/2009 01:34:16

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:

A necesidade de usar-se Design Patterns surge de deficiências na linguagem. No entanto, não importa qual seja a linguagem, sempre existirá um tipo de problema recorrente que não é trivialmente resolvido na linguagem, e um novo Design Pattern poderá ser criado.

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

This message was edited 1 time. Last update was at 06/11/2009 03:16:26

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

MVC foi originalmente um padrão de pequena-escala de Smalltalk-80, e objetos de dados relacionados (modelos), dispositivos da IGU(visões), e manipuladores de eventos do mouse e teclado(controladores). Recentemente, o modelo "MVC" foi adotado pela comunidade de projeto distribuído também para o nível de arquitetura de larga escala.

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!

This message was edited 2 times. Last update was at 06/11/2009 05:20:36

faelcavalcanti wrote: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

MVC foi originalmente um padrão de pequena-escala de Smalltalk-80, e objetos de dados relacionados (modelos), dispositivos da IGU(visões), e manipuladores de eventos do mouse e teclado(controladores). Recentemente, o modelo "MVC" foi adotado pela comunidade de projeto distribuído também para o nível de arquitetura de larga escala.

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!

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.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3420 Offline

faelcavalcanti wrote:
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

MVC foi originalmente um padrão de pequena-escala de Smalltalk-80, e objetos de dados relacionados (modelos), dispositivos da IGU(visões), e manipuladores de eventos do mouse e teclado(controladores). Recentemente, o modelo "MVC" foi adotado pela comunidade de projeto distribuído também para o nível de arquitetura de larga escala.

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.

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

victorwss wrote:
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).

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??

Notícias, artigos e o maior fórum brasileiro sobre Java