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

web2py é feito em python e toda sua api foi pensada e criada antes de sua implementação. Achei interessante postar isso pq as colocacoes do Mochuara, Yuga e Paulo foram interessantes e acho que o extremo sempre será perigoso. Qualquer um dos extremos é bom ter justificativa (ou ser evitado :P)

Uma dúvida, estou metendo a mão agora num sisteminha de controle financeiro. Fico na dúvida de como eu usaria o Patter Account em outra linguagem dita mais dinâmica. Scala já tem esse Pattern? Ruby já tem esse Pattern?

[quote=giulianocosta][quote=mochura]
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.
[/quote]

Uma dúvida, estou metendo a mão agora num sisteminha de controle financeiro. Fico na dúvida de como eu usaria o Patter Account em outra linguagem dita mais dinâmica. Scala já tem esse Pattern? Ruby já tem esse Pattern?[/quote]

A questão não é ser dinâmica (scala é estatica), mas sim ser estensivel. As linguagens que vc mencionou podem ser estendidas para introduzir o pattern que lhe faltam (de uma forma que não é possível com Java).

[quote=mochuara][quote=giulianocosta][quote=mochura]
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.
[/quote]

Uma dúvida, estou metendo a mão agora num sisteminha de controle financeiro. Fico na dúvida de como eu usaria o Patter Account em outra linguagem dita mais dinâmica. Scala já tem esse Pattern? Ruby já tem esse Pattern?[/quote]

A questão não é ser dinâmica (scala é estatica), mas sim ser estensivel. As linguagens que vc mencionou podem ser estendidas para introduzir o pattern que lhe faltam (de uma forma que não é possível com Java).[/quote]

E Java não? Eu posso criar um framework que me abstraia isso da aplicação. Lógico que java não terá alguns “tricks” que teria em Ruby, por exemplo.

Aqui a gente vai voltar a uma discussão lá do início do tópico. Patterns nada tem a ver com linguagens de programação. Pode ser que em algumas linguagens seja mais fácil de contornar um problema por ela te prover um acesso mais abstrato ao problema. Mas isso, em momento algum, torna falseável a utilização dos Patterns.

[quote=mochuara][quote=sergiotaborda]Vamos deixar uma coisa clara - mais uma - se modelar fosse tão ruim, tão anti-util , se tivessemos tanto que evitar modelar, porque raios somos bombardeados com metodologia focadas em encontra o mellhor modelo ? Porque se fala de patterns ? porque se fala de bad smells, anti-patterns, boas práticas , etc… ? Será que é porque modelar é ruim ? ou será que é porque a maioria das pessoas é um mau modelador ?
[/quote]

  1. Se vc faz a modelagem no início que não é por meio de codigo, como vc comunica este modelo? UML? telepatia?
    [/quote]

Que tal conversar ? Já pensou nisso ?
Se vc modela em grupo vc modela na frente de um papel ou quadro e faz bonecos e pela participação de todos se chega num modelo. O modelo não é o que está escrito no papel/quadro. O modelo é aquilo que foi entendido. Ha pessoas que nem precisam de papel e lápis…mas são raras.
Se vc modela sozinho o processo é o mesmo, mas aqui, porque vc apenas pensa e não precisa verbalizar e argumentar é muito mais rápido. Claro que menos eficaz porque uma pessoa sozinha só tem uma prespectiva do problema.

Veja bem, o modelo não é executável porque ele não é fisico, rela, palpavel. Ele existe apenas na cabeça das pessoas e como “directriz” no código. O codigo não é o modelo, é uma representação do modelo. Um UML é outra representação, um teste unitário é outra, um teste de integração é outra e assim vai. São vais faces da mesma coisa, mas a coisa em si mesma não está lá na realidade.
As pessoas usam as suas cabeças para pensar -bom, algumas usam- se o modelo vai ou não ser compativel com os cenários levantados. Repare que um bom modelo pode ser dificil de implementar e uma fácil implementação não é necessáriamente um bom modelo. O modelo tem N implementações possiveis em uma linguagem. Multiplique isso pelas M linguagems que são candidatas e vc terá muitas opções de implementação. o modelo para somar dois numeros é simples, mas a implementação pode ser complexa se eles forem numeros complexos.

Quando vc implementa e executa e dá certo, vc está mostrando que a sua implementação do modelo é válida. Se não funciona não é necessáriamente porque o modelo falha, pode ser a implementação que está errada.

Modelo executável é muito lindo conceptualmente, mas não existe na prática. O que, na prática, se chama “modelo executável” é uma implementação que se vincula artificalmente ao modelo, como se o modelo só podesse ter uma,e apenas uma implementação.

Se isso fosse verdade e o modelo só tivesse uma implementação, essa implementação do modelo não poderia evoluir. E isso não acontece. Para um mesmo modelo a implementação pode evoluir por si.

bom, na realidade não precisa de mim para saber o que é o modelo. Leia sobre modelagem e vc vai entender se ainda restam duvidas. Está-se questionando modelagem sim. Está-se dizendo que não é preciso começar fazendo um modelo. que o modelo nascerá do codigo mágicamente depois de algumas iterações de tentativa e erro. Este modelo pode funcionar quando vc é amador, ou estudante, mas profissionalmente não funciona. Profissionalmente vc precisa dar aval e se comprometer com qualidade e resultados que vc não pode garantir se esperar por milagres do codigo.

Eu acho simples de entender. Vc tem o modelo e vc tem a implementação numa relação 1 para muitos. portanto não ha como dizer que a implementação é o modelo.

Independentemente do que considero que seja o modelo, se ele fica no codigo ou não, o ponto é que tem que existir um modelo.
Uma equipe não pode simplesmente sai programando cada um para seu lado sem que haja um objetivo comum, um algo a alcançar. E esse algo precisa ser compartilhado de forma que todos saibam o que estão tentado alcançar e um caminho tem que ser traçado.
quando vc usa um mapa vc escolhe um caminho. Vc não sabe o que irá acontecer ao longo do percurso que imprevistos haverão. Vc só sabe que a estrada x liga A a B. Agora imagine ir de A a B sem mapa. Vc chega lá, mas não de forma eficaz.

Vc quer ser um vagabundo de código que vai de A a B por tentativa e erro ou vc quer ser um profissional que sabe usar um mapa para ir de A a B ?

BDUF é muito mal compreendido e o pessoal de pseudo-agil usa isso para enganar as criancinhas. BDUF ser ruim é mesmo tipo de asneira que uma equipa sem PO dizer que scrum é ruim.

BDUF não é waterfall. Up front significa no principio. Não significa , “para sempre”.(aliás uma metodologia de desenho não pode comparado a um processo de gerenciamento, mas tudo bem… vou dar essa de barato …)

Como o Paulo falou o problema é na definição de “Big”. Tem uns que acham que Big significa “com todo o detalhe”. Se fosse assim seria big Specification up front. outros, como eu acham que Big design é uma expressão só, como “big picture”. Portanto, BDUF é uma forma compreensivel de enxergar agora as partes necessárias ao sistema. Desse entendimento (eu disse entendimento) são traçadas estratégias tanto de codificação como de organização, para os sprints. Por exemplo, das estorias do backlog vc sabe que existirá uma integração com um sistema proprietáriio de outra empresa. Vc faz um design logo de inicio que separa a responsabilidade da integração do uso. Vc usa truques de programação como uso de interfaces e bridge para isolar o problema da integração em si, que como sabemos é de risco elevado. no primeiro sprint essa estrutura é montada. Todo o mundo sabe o que está fazendo e porquê. No segundo sprint e feito um strub, ou seja,uma classe que parece se comportar como o serviço real, mas não é. Isso permite que sempre possa haver uma demo no final do sprint sem que aintegração exista de fato. lá pelo 8 sprint a integração real está completa. Porque foi implementada a classe real que comunica com o outro sistema. Refactoring zero. Risco zero. Porque houve um design logo de inicio que entendeu “the big picture” e solucionou sem esforço. O mecanismo é ha prova de alterações por design , não por engenharia. Imagine agora que no 5° sprint o PO fala que o contrato com a empresa que iria fornecer o serviço foi abortado e que em vez será feita a interface com outro sistema de outra companhia. O que mudou para a equipe e para o projeto ? Nada. A estratégia continua sendo a mesma e no 8° sprint continuaremos tendo a integração real completada. Reação à mudança se planeja. Simplesmente mudar tudo pela pura força bruta é um trabalho herculeano. E Hercules é um cara da mitologia, ou seja, não existe de facto ninguem que possa apenas pela força bruta mudar as coisas.

O problema com o BDUF é modelar coisas que serão inuteis. Coisas a mais. Se vc se deixar levar vc tá ferrado. Mas se vc modelar apenas o suficiente isso tem muitos ganhos. O fato de ter um plano, ter um design no inicio do projeto ajuda em muitas coisas. Ajuda na comunicação, ajuda no foco, ajuda do compromisso. Como as pessoas se podem comprometer como que é desconhecido ?

Scrum é planejamento. Tudo é planejado. A diferença para o processo tradicional é que o plano é mutável. Constantemente. Planejar é tudo , o plano é nada.
Mas um plano só pode ser mudado se ele existir. Essa é a máxima do scrum e do agil em geral. Panning Poker, Sprint Planning, Scrum Planning … nos livros vc lê “O scrum começa com o projet backlog” ,ok, mas como se chegou nisso ? magia ? epifania ?
Vc ainda não respondeu como cria o Product Backlog sem ter um modelo. Nem explicou como a equipe pode criar o sprint log sem ter um modelo. Como vc acha que se chega num backlog de produto. Como você chega em um ?

[quote]

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. :)[/quote]

Ok, já sabemos a sua opinião sobre a utilidade do patterns e os fracasso das linguagens OO. não ha nenhuma que tenha todos os padrões incluidos, logo, todas são imcompletas se seguirmos a sua definição. informação tautologica é informação inutil.

[quote=sergiotaborda]
Neste mecanismo vc tem no máximo 1 sprint para conseguir o modelo e algo outro algo que seja demonstrável. por isso é muito preferivel usar o sprint zero (Planning Metings) para polir o modelo ao máximo. E note que isto é feito por todos os participantes não apenas o implementador. [/quote]
Que outras responsibilidades são compartilhadas no Sprint zero, como isso é feito por participantes que não são implementadores, simplesmente opinam ?

[quote=Crocodilo][quote=sergiotaborda]
Neste mecanismo vc tem no máximo 1 sprint para conseguir o modelo e algo outro algo que seja demonstrável. por isso é muito preferivel usar o sprint zero (Planning Metings) para polir o modelo ao máximo. E note que isto é feito por todos os participantes não apenas o implementador. [/quote]
Que outras responsibilidades são compartilhadas no Sprint zero, como isso é feito por participantes que não são implementadores, simplesmente opinam ?[/quote]

Antes de começar os sprints é preciso um backlog e é preciso estimá-lo em SP.
O desenho do backlog, o que vai e não vai, como vai, separação de estoria, fusão de estorias,etc é um trabalho conjunto do PO equipa e SM (para impor as regras scrum), mas o PO pode trazer que precisar, tlv um perito no dominio. A responsabilidade é do PO, mas ha feedback de todos os interessados, sobretudo da equipe de desenvolvedores. E sim, eles opinão. Argumentam, exercitam os cenários, etc… é um brainstorm completo. Galinhas podem participar também , mas eles participam como adjuntos ao processo para esclarecer coisas e ajudar ao brainstorm. (Galinhas são pessoas que não são diretamente comprometidas com o projeto mas participam dele de alguma forma. o exemplo simples: perito no dominio)

Veja o desenho aqui . Esta imagem acompanha um texto escrito pelo ken schwaber ( o cara que 'inventou" o scrum).

Veja que ha um passo que não é iterativo que dá o pontapé no ciclo de sprints. Este passo é o passo de planejamento.

Onde isso foi dito? “refactor driven development é suicidio” para voce siginifica “refactor é suicidio”???
Acho que voce se enganou… ou voce tambem acha que dizer “não uso test driven development” é a mesma coisa de dizer “não faço testes nenhum”???

falando em design patterns, e meio que de última hora, para quem é de recife, amanhã vai rolar um mini-curso que estarei dando sobre design patterns.
fiquei meio off, e achei muito legal esta thread, e não tinha visto! obrigado paulo por nos elucidar!

mais informações: http://faelcavalcanti.wordpress.com/

[quote=giulianocosta][quote=mochuara][quote=giulianocosta][quote=mochura]
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.
[/quote]

Uma dúvida, estou metendo a mão agora num sisteminha de controle financeiro. Fico na dúvida de como eu usaria o Patter Account em outra linguagem dita mais dinâmica. Scala já tem esse Pattern? Ruby já tem esse Pattern?[/quote]

A questão não é ser dinâmica (scala é estatica), mas sim ser estensivel. As linguagens que vc mencionou podem ser estendidas para introduzir o pattern que lhe faltam (de uma forma que não é possível com Java).[/quote]

E Java não? Eu posso criar um framework que me abstraia isso da aplicação. Lógico que java não terá alguns “tricks” que teria em Ruby, por exemplo.

Aqui a gente vai voltar a uma discussão lá do início do tópico. Patterns nada tem a ver com linguagens de programação. Pode ser que em algumas linguagens seja mais fácil de contornar um problema por ela te prover um acesso mais abstrato ao problema. Mas isso, em momento algum, torna falseável a utilização dos Patterns.[/quote]

Não. A linguagem Java não foi feito pra ser extensível, por isso frameworks Java não chegam nem perto de obter o mesmo resultado que linguagens feitas pra serem extensíveis, eles apenas varrem a sujeita pra debaixo do tapete.

[quote=giulianocosta]
Aqui a gente vai voltar a uma discussão lá do início do tópico. Patterns nada tem a ver com linguagens de programação. Pode ser que em algumas linguagens seja mais fácil de contornar um problema por ela te prover um acesso mais abstrato ao problema. Mas isso, em momento algum, torna falseável a utilização dos Patterns.[/quote]

É fato que patterns tem que ser utilizados aos montes por programadores Java, enquanto que outras linguagens ditas de alto-nivel é possivel abstrair os patterns dos seus programadores. Portanto não consigo chegar na mesma conclusão que vc, patterns tem TUDO A VER com a linguagem de programação utilizada.

Não entendi essa parte.

Bom, eu trabalho com a perspectiva de que o código é o modelo, e o bytecode é uma representação deste modelo, gostaria de saber sua opinição sobre isto.

O que tu entendes como uma linguagem “extensível”?

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.

Eu chego a essas respostas com estimativas baseado, entre outras coisas, nos requisitos do sistema. Parece que o que vc chama de modelo é o que eu chamo de estimar, supor. Não concordo que patterns sejam uteis nessa fase inicial e por isso cheira waterfall o que vc descreve pra mim e outras pessoas aqui do forum.

[quote=ccaneta]

Bom, gostaria de saber quais seriam as suas observações já que você Guerra é um conhecedor também sobre o assunto.

; )[/quote]

Na verdade temos diversas técnicas para nos auxiliar no momento de realizar a modelagem de um sistema como a criação de diagramas, TDD, refactoring e etc… Antes do refactoring não existia nenhuma técnica que permitia que você trabalhasse em cima da modelagem depois que o código estivesse pronto. Por isso as técnicas de modelagem mais antigas buscavam uma solução definitiva que procurava prever todas futuras questões que poderiam surgir e isso é que as tornavam não-ágeis. Utilizando essas técnicas em conjunto com refactoring, não existe mais aquela idéia de encontrar “a solução” e sim de encontrar uma solução que funcione. Se ela não for a melhor, refatore depois!

O balanço do quanto de modelagem deve ser feito antes e depois acho que é um equilíbrio que cada equipe deve buscar. Se existisse uma receita de bolo, não teria muita graça, não é mesmo…

[quote=mochuara][quote=sergiotaborda]
Modelo executável é muito lindo conceptualmente, mas não existe na prática. O que, na prática, se chama “modelo executável” é uma implementação que se vincula artificalmente ao modelo, como se o modelo só podesse ter uma,e apenas uma implementação.

Se isso fosse verdade e o modelo só tivesse uma implementação, essa implementação do modelo não poderia evoluir. E isso não acontece. Para um mesmo modelo a implementação pode evoluir por si.
[/quote]

Não entendi essa parte.

Bom, eu trabalho com a perspectiva de que o código é o modelo, e o bytecode é uma representação deste modelo, gostaria de saber sua opinição sobre isto.[/quote]

Bom, eu não vejo assim. Existe uma relação directa e até bijetiva entre o codigo e o bytecode chamadas compilador e descompilador.
Suponho que em algum contexto se possa pensar no codigo como sendo o modelo, mas é a primeira vez que ouço isso e simplesmente , para mim, não faz sentido. Modelo é o que deu origem ao código em primeiro lugar. Ou melhor, modelo é a razão para o codigo ser assim e não de outra forma.

[quote=mochuara][quote=sergiotaborda]
Scrum é planejamento. Tudo é planejado. A diferença para o processo tradicional é que o plano é mutável. Constantemente. Planejar é tudo , o plano é nada.
Mas um plano só pode ser mudado se ele existir. Essa é a máxima do scrum e do agil em geral. Panning Poker, Sprint Planning, Scrum Planning … nos livros vc lê "O scrum começa com o projet backlog" ,ok, mas como se chegou nisso ? magia ? epifania ?
Vc ainda não respondeu como cria o Product Backlog sem ter um modelo. Nem explicou como a equipe pode criar o sprint log sem ter um modelo. Como vc acha que se chega num backlog de produto. Como você chega em um ?
[/quote]

Eu chego a essas respostas com estimativas baseado, entre outras coisas, nos requisitos do sistema. Parece que o que vc chama de modelo é o que eu chamo de estimar, supor. [/quote]

Não. Se é isso que lhe parece vc não está dentro do contexto. Modelo não é estimar. Isso não faz sentido.

[quote]
Não concordo que patterns sejam uteis nessa fase inicial e por isso cheira waterfall o que vc descreve pra mim e outras pessoas aqui do forum.[/quote]

Obviamente que design patterns não servem para estimar. Mas nunca ninguem falou que sim. Isso foi vc que entendeu.

Requisito é o que o cliente deseja, modelo é um conjunto de ideias de como podemos satisfazer esse desejo. Vc não implementa requisito por requisito. Com 1000 requisitos vc não tem 1000 softwares. O modelo é o que lhe permite condensar esses 1000 requisitos em N (N<<<< 1000) funcionalidades que serão implementadas.

por exemplo, existem inumeras formas de montar uma expressão matemática. Um interpretador de expressões matemáticas utiliza um modelo que permite tratar todas independentemente de quais são. O que estou dizendo é que para cada situação existe um modelo melhor que uma implementação ad hoc. O desenvolvedor deve procurar esse modelo e basear-se nele. Como vc faria um intepretador de expressões matemáticas? Cada um faria de um jeito. Mas se vc souber que o modelo - comprovadamente melhor- é o de um stack (pilha) vc estaria começando com muita vantagem em relação a alguem que começou ad doc. Pilha é um modelo. Utilizar a pilha para esse fim é um modelo. Depois teremos uma implmentação disso, mas o foco aqui é no modelo em si.

Agora que sei que devo ter uma pilha de expressões matemáticas tão simples que as possa computar, vou estruturar meu modelo de classes em torno disso. alguns padrões que me podem ser uteis eu já conheço ( Interpreter e Iterator, por exemplo) mas isso não significa que vou arranjar um jeito de os colocar lá. O que vou fazer é seguir OO até encontrar todas as classes e responsabilidade. Todo este mecanismo estara em uma classe de forma que possa fazer classe.calculate("2+4") e essa classe é por definição um interpreter. Isso já me dá uma visao de quais outras classes preciso, e assim vai. O padrão é uma ajuda, um catalizador do processo de modelagem mas o processo em si é guiado por regras OO como injeção de dependencia, inversão de controle, separação de responsabilidade, etc…

Depois que tiver o modelo completo que me permite obter de uma expressão matemática o resultado, ai eu vou estimar o esforço para fazer isso.

Eu sigo uma máxima que diz: "não precisa funcionar, tem que ser facil de alterar" se funcionar otimo, se não funcionar, porque é facil de alterar, vc colocar funcionando com pouco esforço.
O meu ponto é apenas que modelar seguindo padrões e boas práticas resulta em um modelo mais proximo do necessário e mais amigável à mudança.

[quote=giulianocosta]
O que tu entendes como uma linguagem “extensível”?[/quote]

Uma linguagem que permite ser extendida pra acomodar as abstrações que não pertecem ao core da minha aplicação.

[quote=giulianocosta]
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.[/quote]

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. (Não sou a pessoa mais indicada pra falar de Ruby, mas creio que Ruby seja um avanco em relação a Java nesse sentido).

[quote=mochuara]

[quote=giulianocosta]
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.[/quote]

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.[/quote]

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.

Cara, sinceramente não da pra te entender. Aqui tu diz:

Tu deixa claro que só Java tem que se usar Design Patterns e em outras linguagens de mais alto nível eles são absorvidos pela linguagem.

E aqui tu fala que não teria sentido, no caso o “Ruby”, a exemplo, abstrair o tal Pattern que estou citando. Mas ao mesmo tempo tu da a idéia que Patterns só são usados por Desenvolvedores Java e que em linguagens como Ruby não são necessários.

Sinceramente não consigo te entender. Ou você não leu todo o tópico ou você não faz a minima idéia do que um Pattern venha ser.

[quote=sergiotaborda][quote=mochuara]

[quote=giulianocosta]
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.[/quote]

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.[/quote]

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]

:shock: bem que parece mesmo que voces estavam falando sobre coisas diferentes…