Qual DESIGN PATTERN ATENDE ESSE PROBLEMA?

Olá

Faz ao contrário.

Primeiro desenvolva a solução para seu problema sem pensar em patterns, nome de patterns ou qualquer coisa semelhante.

Costumo dizer que Design Patterns é uma armadilha e ao mesmo tempo barreira na criatividade para quem está mais ou menos no início do seu amadurecimento. Quando o cara está na dúvida sobre patterns é justamente uma indicação de que ele ainda não está maduro para usar.

É claro que acho que uma das melhores maneiras de aprender é ler código dos outros. Vasculhar projetos Open Source e código dos seus companheiros. Imagino que esta etapa você já vem fazendo faz tempo. Então já deve ser capaz de escrever seu próprio código.

Para mim, que aprendi no tempo em que os patterns ainda não existiam, acho melhor que você procure solução para seu problema usando estritamente o que sabe. Invente a roda se for preciso. Não siga modelos prontos.

Quando você tiver bastante experiência, aí começará a reconhecer os padrões que sozinho saltarão aos olhos e perceberá claramente quais podem ajudá-lo.

[]s
Luca

Olá, Luca

Obrigado pelo conselho, penso da mesma maneira em relação de usar o que sabemos para resolver o problema.

Mas nesse caso precisamos restritamente de usar o Design Pattern, cada pessoa de meu grupo tentará apresentar um modelo ideal, porém ninguém tem experiência no assunto, apenas teoricos.

`Justo é essa nossa tarefa’ aplicar os pattern para fazer o forum, apesar de todos ter feito um mini-curso do GOF, na prática é uma armadilha como disse!!!

Agora para nos so resta em trocar experiências com pessoas que usam o Design Pattern. Agradeço se tiver algum modelo para o problema apenas para ajudar em qual eu estou fazendo.

SE ALGUÉM MAIS SE MANIFESTAR EU AGRADEÇO, POIS PARA MIM ACHO QUE COLOQUEI NO FORUM CERTO QUE É DE ASSUNTOS AVANÇADOS, ME CORRIJAM SE TIVER ERRADO! E AGRADEÇO DESDE JÁ QUE PUDER DAR UMA MÃO!!

O código do JForum (ou seja, deste forum) é open source. Por quê você não baixa o código e vê quais os design patterns o pessoal usou? Como ele foi desenvolvido por bons programadores, provavelmente você encontrará os patterns usados da maneira correta.

[]s

Iavh, valeu pela dica sim…pois além do jforum ser open ele faz parte do SAKAI LMS(Sistema EAD) que estou começando a trabalhar…

Ele é um pouco grande, não sei se vou conseguir a tem encontrar, pois seria mais uma análise.

Mas se eu tiver sorte eu encontro alguma coisa lá. O problema mesmo é vivência com Pattern, para identificar os pattern é muito difícil para quem não tem experiência, pois seria mesma coisa do projeto do forum, porém maior, mas com esse projeto podemos comparar no final!!,…por isso valeu a dica.

Mas se alguém puder me indicar qual ou quais pattern se encaixa nessa situação seria bom, pois para saber o Pattern a pessoa deve ser alguém com muita experiência mesmo… alguém que trabalha com isso…por isso coloquei aqui no forum, pois sei que aqui seria o melhor lugar e até agora as dicas são boas!! Normalmente o pessoal de Java usa pattern, mesmo sem saber como eu fazia antes, rs.

Bem aguardo mais dicas e opiniões, pois parece que Design Pattern é algo difícil mesmo, ou seja, os livros não respondem nada, apenas experiência é capaz de indicar um Pattern ou Pattern na solução. Como eu disse antes vou usar um Comand para cada situação e uma factory… Mas será que outros pattern não se encaixaria melhor???

Olá

Insisto.

Tente escrever seu código sem pensar em patterns. Se você tem boa prática de programação, já escreveu muito código e conhece BEM os patterns, eles saltarão a vista na hora de usá-los.

Se você está em dúvida sobre qual usar é sinal de que NÃO conhece bem. Então NÃO deve usar. Se na sua equipe tem alguém que conhece BEM, então cabe a ele explicar a opção de usar este ou aquele pattern.

E se perguntar ao Rafael Steil se ele usou patterns, provavelmente a resposta será não. Ele desenvolveu o JForum justamente com intuito de aprender Java. Sabe porque ele conseguiu um bom resultado? Justamente porque não ficou pensando em patterns e partiu para o chamado “Get Things Done”.

Não sou contra o uso de patterns. Sou a favor de priorizar a solução do problema. Se isto redundar no reconhecimento de algum pattern, ótimo. Mas para reconhecer tem que ter experiência.

É como costumo dizer: o pattern correto salta aos olhos de quem sabe reconhece-lo. É como diferenciar uma cobra venenosa de uma não venenosa. Se está na dúvida, fuja dela.

[]s
Luca

Pois é, mas o pessoal quer usar PATTERN, a questão é que apartir de agora so usaremos pattern nos projetos, há apenas uma pessoa no projeto que é o arquiteto, porém ele deixou essa “missão para nós”, pois fazer algo depois de um curso é para aprender e tal, o pessoal quer usar Pattern pois não é meu grupo que decide o quê é melhor, mas sim os donos do projeto. Como eu disse antes: só quem tem experiência pode indicar qual Pattern utilizar, ou alguém que esteja trabalhando com isso ou possui algum exemplo de forum com Pattern.

Pelas boas práticas da Engenharia de Software o Design Pattern é recomendado, e deve ser usado, já que algo difício para iniciante então em minha opinião acho que é possível usar desde que haja interesse, e errar faz parte do aprendizado. O problema é que para todos da equipe é uma nova fase, não estamos mais presos a tecnologias como antes, agora todo projeto será usado Eng. de Software e tudo que garanta padronização e qualidade. O Design Pattern é algo feito para ajudar esse processo, “mesmo que muitos não gostem, inclusive para quem esta começando como eu”.

Acho que aqui mesmo no Forum eu vi algo do Guerra na Mundo Java dando um exemplo de Pattern e na Caelum há um curso de segurança e Design Pattern, porém exemplos ajudam e muito se for real e aplicado. Mas infelizmente nem sempre o Guerra ou o Paulo, Guilherme estão vendo o forum ou outros que usam Design Pattern.

Como eu disse: quero saber se os modelos que eu irei usar estão de acordo ou quais seriam melhor???

Olá

Só para finalizar…

Aqui tem um monte de gente que sabe reconhecer padrões. Para estas pessoas os padrões saltam aos olhos.

Para quem não tem experiência e está na dúvida sobre qual usar, pelo menos para mim uma das duas coisas seguinte está acontecendo:

1. falta conhecimento sobre padrões e isto se resolve com estudo

2. falta tentativa de escrever código porque padrões no fundo são padrões de código. Para comparar é preciso ter algo escrito.

Não adiantará nada alguém dizer use X ou Y se vocês ainda não sabem bem as motivações por trás da existência do padrão.

[]s
Luca

Só para finalizar…

Aqui tem um monte de gente que sabe reconhecer padrões. Para estas pessoas os padrões saltam aos olhos.

Para quem não tem experiência e está na dúvida sobre qual usar, pelo menos para mim uma das duas coisas seguinte está acontecendo:

1. falta conhecimento sobre padrões e isto se resolve com estudo

2. falta tentativa de escrever código porque padrões no fundo são padrões de código. Para comparar é preciso ter algo escrito.

É de certa forma é isso mesmo, mas não é preciso implementar código para escolher o PATTENER!!! Aí que esta. Implementar código e depois escolher o Pattern??

Temos o caso de uso que passei perguntando(ALGO ESCRITO!!!). A questão aqui não é falta de estudo, pois se fosse isso não tinha perguntado se os Pattern que escolhi estavam corretos, primeiramente se escolhe o Pattern e depois você implementa, se alguém faz código e depois escolhe o Pattern poderá trabalhar duas vezes, pois se escoher o Pattern errado não terá sucesso, além disso o Design Pattern faz parte da UML (GOF), a maioria do pessoal usa Pattern sem saber, o JAVA possui seus próprios Pattern e tal, mas se for procurar qualquer um que usa Design Pattern ninguém escreve código e depois IMPLENETA O MODELO.

NÃO ESTAMOS FALANDO DE CÓDIGO, MAS SIM De QUAL PATTERN ESCOLHER MELHOR NESSA SITUAÇÃO, O CÓDIGO PODE ATÉ SER GERANDO COM CASE SE USAR ALGUMA FERRAMENTA especialista.
EU SEI QUE AQUI TEM UM MONTE DE GENTE QUE SABE USAR PATTERN, POR ISSO EU POSTEI: Mas infelizmente nem sempre o Guerra ou o Paulo, Guilherme estão vendo o forum ou outros que usam Design Pattern.

SE EU JÁ SOUBESSE CORRETAMENTE QUAL USAR EU NÃO ESTARIA PERGUNTANDO NO FORUM! ACHO QUE ELE É FEITO PARA ISSO.

NÃO ESTOU PEDINDO PARA FAZER PARA MIM, MAS SIM ALGUÉM QUE DIZ COM SUA EXPERIÊNCIA SE IREI TER SUCESSO OU NÃO NA IMPLENTAÇÃO DOS DESIGN PATTERN QUE ESCOLHI, POIS SE HOUVER COMENTÁRIO E TAL EU AGRADEÇO.

POSTEI AQUI POIS MINHA DÚVIDA NÃO É O QUE CADA PATTERN FAZ, A SITUAÇÃO É DE RECONHECER O PADRÃO QUE SE ENCAIXA COM O PROJETO, NOSSO AMIGO ESCREVEU ALGO:

http://www.guj.com.br/posts/list/195/142721.java#775418

faelcavalcanti wrote:

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


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!</blockquote>

Saber como usar é entender como funciona o Façade, por exemplo, que cara ele tem, como implementar e que mecanismo ele usa.
Saber quando usar é identificar onde ele deve ser usado e onde ele não deve ser usado. Afinal, como eu já disse outras vezes aqui no GUJ, usar um padrão no lugar errado, na circunstância errada, transforma o padrão em anti-padrão.

http://www.guj.com.br/posts/list/60767.java

ENTÃO, NESSE FORUM DE METODOLOGIAS ELES ESTÃO DISCUTINDO O QUE O PATTERN FAZ E ALGUMAS DIFERENÇAS, NO CASO ESTOU PERGUNTADO PARA OS DESENVOLVEDORES A PARTIR DO SEGUINTE PROBLEMA: “existe algum design pattern conhecido que resolva este problema?”, NO CASO EU ENCONTREI DOIS PATTERN COMMAND E FACTORY QUE USAREI, MAS APENAS ESTOU EXPONDO O PROBLEMA COM CASO DE USO (PARA QUEM É ANALISTA DE NEGÓCIO OU CONHECE UML NÃO HÁ DIFERENÇA PARA ENTEDER O CASO DE USO OU VER O CÓDIGO, AMBOS SÃO CONSIDERADOS CORRETOS PARA ENTENDER, MAS SE FOR ANTES DE CÓDIFICAR O ESTUDO DE CASO ATRAVÉS DE CASO DE USO É O MAIS FÁCIL PARA APRESENTAR)

PARA MIM ESSA PERGUNTA SO FECHARÁ SE ALGUÉM ME RESPONDER SOBRE A SITUAÇÃO (O CASO DE USO ESTA NA DESCRIÇÃO DA PERGUNTA).

PESSOAL, minha questão é simples. Acho que esse forum a opinião é livre e tal. Minha pergunta é sobre Pattern. Quando eu faço a pergunta sobre Patter é para tirar dúvidas, uma vez perguntei para o GUERRA (Mundo JAVA - Prof do ITA), qual PATTERN devo usar para meu projeto, ele simplesmente perguntou o que eu queria apresentar no meu diagrama, então ele falou qual Patter usar e cabou. Ele estava certo e não precisei implentar outro Pattern.

É simples para que sabe UML bem, e tem muita experiência…Más com certez há muitos que sabem só de olhar o caso de uso que descrevi quais Patterns que preciso usar…

Pois sei da capacidade de profissionais e professores como da Caelum e pessoas que trabalham a muito tempo com Pattern.

Agradeço que puder me dizer qual pattern seria ideal para meu problema.

No caso vou fazer uma diagrama para todos e depois vou fazer um command para cada situação. Então até amanhã posso colocar algum modelo aqui do que estou desenvolvendo.

Acho que você está um pouco confuso, na minha opnião.
Qual é o seu problema? O seu problema é modelar um Forum? Então não existem design patterns para modelar Foruns.

Agora tente fazer o modelo. No seu modelo quando, e se, você se deparar com problemas específicos como a necessidade de armazenar o estado interno de um objeto em um determinado momento, para que seja possível retorná-lo a este estado, ou precisar representar um objeto que é constituído pela composição de objetos similares a ele, ai você poderá aplicar patterns como Memento e Composite, por exemplo, para resolver seu problema.

Agora se você quer simplesmente USAR PATTERNS no seu projeto, só por usar, você pode escolher qualquer um, ou até TODOS, porque o sentido dos patterns já se perdeu mesmo.

OLÁ PESSOAL,

FELIZMENTE UM COLEGA ENCONTROU UM MODELO DO DESIGN PATTERN QUE SE ENCAIXA NA SITUAÇÃO EM MODELAR UM FORUM DESCRITO NA MINHA PERGUNTA.
O PATTERN É O MVC DO GOF QUE PODE SER APLICADO EM QUALQUER LINGUAGEM PARA QUEM NÃO POSSUI CONHECIMENTO.

AQUI UM EXEMPLO DE DESIGN PATTERN MVC:

http://java.sun.com/blueprints/patterns/MVC.html

BEM, DEPOIS QUE ESCOLHEMOS CORRETAMENTE O DESIGN PATTERN (SERIA O TRABALHO DO ARQUITETO DO PROJETO) AGORA ESTAMOS IMPLEMENTANDO O MESMO E SEM DIFICULDADES!

COMO EU DISSE ANTES: O TRABALHO DE ESCOLHER UM PATTERN ANTES DO CÓDIGO É ALGO MUITO IMPORTANTE, SERIA UMA ANÁLISE QUE O ARQUITETO DO PROJETO DEVE ECOLHER ANTES DE IMPLEMENTAR, OU SEJA, É UM NÍVEL ACIMA DE QUALQUER DESENVOLVEDOR, PARA QUEM NÃO CONHECE ENGEMHARIA DE SOFTWARE E ACHOU O QUE EU POSTEI É UM ABSURDO ENTÃO ESSE CURSO SERIA ESSEANCIAL PARA QUEM QUER REALMENTE SABER COMO FAZER AS COISAS DIREITO COM PADRÕES E NORMAS, ETC.

FLW

Olá

1. Absurdo mesmo é responder em foruns escrevendo tudo em maiúsculas. Um pouquinho de netiqueta não faz mal a ninguém.

2. E continuo com a mesma opinião. Design Patterns, pelo menos os do GOF, são padrões de código. Servem para unificar trechos de código. Se o arquiteto é alguém com larga experiência de codificação e que sabe as motivações da existência de cada padrão, então há chances de que acerte na escolha. Mas se for um emgenheiro de software…

3. Se você acha que só pela escolha do MVC todos seus problemas estão resolvidos, parabéns e boa sorte.

[]s
Luca

1. Design Pattern não são padrões de código de nenhuma maneira, além disso faz parte da UML. Para melhorar os conceitos do que é Design Pattern é sempre bom fazer uma pesquisa em bibliográfia, nem se for começar pela internet e depois ir para livros: (Design Pattern é Padrão de Projeto)

http://pessoal.facensa.com.br/daniel/files/lp2/WILDT_JAVAPATTERNS.pdf
http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/pat/oque.htm
http://codeigniterbrasil.com/passos-iniciais/padroes-de-projeto-ou-design-patterns-o-que-sao-para-que-servem-e-qual-sua-implicacao-de-uso/
LARMAN, Craig. Utilizando uml e padrões, e outros

2. Para ser um engenheiro de software precisa de muita experiência mesmo, não apenas de programação:

http://www.timaster.com.br/revista/raiox/raiox.asp?prof=82&entrevista=nao

Engenheiro de Software

Descrição: Profissional responsável por criar, manter e auditar metodologias de desenvolvimento de sistemas em uma empresa.

Formação recomendada: Nível superior em Engenharia de Sistemas, Matemática ou Informática.

Conhecimentos úteis: Linguagens de programação, análise de sistemas, ambientes de tecnologia, planejamento e controle de processos. Linguagem UML (Unified Modeling Language), para modelagem de dados da aplicação. Ferramentas de desenvolvimento de software. Recomendável também conhecimento em planejamento administrativo.

Ferramentas necessárias: Ferramentas Case para auxiliar no desenvolvimento de software. Ferramentas específicas para cada linguagem de programação (Visual Basic, Delphi etc).

…

O Engenheiro de software é que possui o segundo melhor salário nos EUA, então eu trabalho com Eng. de software da Alemanhã e dos EUA, e pode ter certeza que nenhum Arquiteto possui a experiência deles, além disso o termo engenharia de software aqui no Brasil é novo. O pessoal aqui no Brasil estão “começando” a pensar em Qualidade (QA), para ter uma idéia, apenas 5 Engenheiros de Software possui a Certificação SQA americana, e as empresas aqui não querem contratar um Engenheiro de Software por achar que 2000 mil reais por dia é muito, preferem ter fé nos programadores, aí dizem que não tem recursos para pagar um proissional desse gabarito, e no final muitas vezes acabam refazendo o projeto e gastando muito mais.

3. Sim, eu acho que escolhendo uma boa arquitetura e padrão de projetos terei mais sucesso,é para isso que eles são feitos.

Aqui é um forum, mas infelizmente as pessoas confundem uma resposta ou impor opiniões, que foi no caso das respostas que tive até agora. Então, antes de criticar faça uma pesquisa, pois outros leitores irão procurar uma questão semelhante a minha e vai encontrar respostas sem fundamento e incorreta.
Então, é isso!!

E só um detalhe, o MVC não é padrão de design, e sim de arquitetura. Ele está mais relacionado à divisão de tarefas, e não à funcionalidade.
Eu recomendo que siga a dica do Luca. Tente montar o diagrama de classes da sua solução e, a partir dali, tente deduzir que patterns poderiam ser usados.

De cara, creio que o Composite vai ser um deles. Ele é geralmente um pattern conveniente para agrupar coisas, como o fórum agrupa. E muito provavelmente aparecerá também um Strategy ou outro. Como o fórum é uma estrutura em árvore, pode também aparecer um Visitor. Factory Method é um outro pattern que dificilmente deixa de existir. Mas não existe um único pattern num sistema complexo como esse. Se você quer mais detalhes, diga qual parte do sistema está modelando, que patterns está pensando em usar e porque, que então podemos discutir se você está certo em suas colocações. Mas você só falou no command, não disse nem onde, nem para que e nem porque escolheu o pattern.

Não é questão de confundir. Eles estão tentando desfazer uma confusão que está na sua cabeça. Quem está tentando impor a opinião de que existe um pattern só (ou poucos) para o sistema inteiro aqui é você, e você se ofendeu porque está sozinho nessa opinião. Agora, pergunte-se… quem será que está errado? Você, sozinho, ou todos os outros profissionais daqui que tem alguns anos de carreira?

O pessoal só está pedindo para você modelar melhor o problema, e então discutir as partes específicas desse modelo. Não existe um “pattern mestre” que irá guiar o desenvolvimento do seu sistema inteiro.

Quanto ao seu texto com letras maiúsculas. Você assumiu uma postura arrogante de que o Luca e os demais colegas não sabem o que estão dizendo. Muito provelmente os outros colegas que você indicou te mandariam fazer a mesma coisa. O que ninguém vai fazer aqui é sentar e modelar o sistema para você.

Se você que ser um engenheiro de software, o primeiro passo é entender bem o que está dizendo.

Outra coisa, movi o tópico para o fórum “Arquitetura de Sistemas”. Esse assunto, como você mesmo ressaltou, não tem nada a ver com código. Você está interessado apenas na arquitetura. Então, o fórum de Java avançado não é o mais relevante, já que lá fala-se de codificação usando os recursos avançados do Java.

PS: Se você ler as referências que você mesmo postou, vai ver que a maioria cita os patterns como “soluções para problemas comuns”, “modelos de interações entre classes” e “soluções de micro-arquitetura”. Na sua proposta, você ainda nem sequer chegou ao problema, não modelou as classes (que era o que o Luca estava pedindo para você fazer) e não está lidando com uma micro-arquitetura, mas com uma macro, referente ao sistema todo. Portanto, pelas suas próprias referências, você está errado em suas colocações.

Eu tenho o livro do Larman que você citou. E li de cabo a rabo. Ele explica como identificar patterns em vários pontos do sistema, e faz isso durante três iterações de um sistema de PDV. Sugiro que você mesmo leia o livro, ao invés de só cita-lo, e tente aprender a metologia o autor. Veja a forma com que ele faz, e note que é incremental, relacionada ao problema específico, e durante a fase de analise do sistema e dos diagramas de classe.

Pra começar seu amigo já está errado porque o MVC não é um padrão do GOF, como você diz.

Pra mim e para muitos tb, MVC é uma arquitetura e não um design pattern. É aplicavél em qualquer sistema em que se deseja ter uma separação mais clara da interface, modelo e lógica do negócio (Model - View - Controller), principalmente em projetos web, mas não somente.

Sua pergunta foi quais design patterns usar, na camada Controller vc pode usar Command, na Camada View vc pode usar Composite, por exemplo, MAS REPITO: os patterns servem pra resolver problemas do modelo, são soluções consagradas pra problemas específicos. Se vc não tem um modelo e não tem problemas pra resolver, não tem pq usa-los.
Se algum amigo seu achar um pattern milagroso para o seu forum, não ouça o que ele diz, pq com certeza está falando besteira.

Amigo pq vc acha q não obteve muitas respostas produtivas aqui?? Eu acredito que de seu post não fez muito sentido e demontra que você conhece pouco do assunto, mas é claro que isso não é o problema!!! Pelo contrário, é o objetivo deste fórum esclarecer dúvidas e agregar conhecimento, o problema é que você simplesmente está ignorando ou refutando todas as opniões e esclarecimentos de pessoas que tem, pelo menos, um pouco mais de experiencia do que vc.

[]'s

ViniGodoy:

E só um detalhe, o MVC não é padrão de design, e sim de arquitetura. Ele está mais relacionado à divisão de tarefas, e não à funcionalidade.
Eu recomendo que siga a dica do Luca. Tente montar o diagrama de classes da sua solução e, a partir dali, tente deduzir que patterns poderiam ser usados.

De cara, creio que o Composite vai ser um deles. E muito provavelmente aparecerá também um Strategy ou outro. Mas não existe um único pattern num sistema complexo como esse.

Não é questão de confundir. Eles estão tentando desfazer uma confusão que está na sua cabeça. Quem está tentando impor a opinião de que existe um pattern só para o sistema inteiro aqui é você, e você se ofendeu porque está sozinho nessa opinião. Agora, pergunte-se… quem será que está errado? Você, sozinho, ou todos os outros profissionais daqui que tem alguns anos de carreira?

Quanto ao seu texto com letras maiúsculas. Você assumiu uma postura arrogante de que o Luca e os demais colegas não sabem o que estão dizendo. Muito provelmente os outros colegas que você indicou te mandariam fazer a mesma coisa. O que ninguém vai fazer aqui é sentar e modelar o sistema para você.

Se você que ser um engenheiro de software, o primeiro passo é entender bem o que está dizendo.

Outra coisa, movi o tópico para o fórum “Arquitetura de Sistemas”. Esse assunto, como você mesmo ressaltou, não tem nada a ver com código. Você está interessado apenas na arquitetura. Então, o fórum de Java avançado não é o mais relevante, já que lá fala-se de codificação usando os recursos avançados do Java.

PS: Se você ler as referências que você mesmo postou, vai ver que a maioria cita os patterns como “soluções para problemas comuns”, “modelos de interações entre classes” e “soluções de micro-arquitetura”. Na sua proposta, você ainda nem sequer chegou ao problema, não modelou as classes (que era o que o Luca estava pedindo para você fazer) e não está lidando com uma micro-arquitetura, mas com uma macro, referente ao sistema todo. Portanto, pelas suas próprias referências, você está errado em suas colocações.

Ops não vi essa resposta antes de postar…Concordo 100%

O cara abre uma thread pra dizer que vai usar MVC??? não tinha nem que ter pensando pra inserir isto, até pq isto jah está implícito em qualquer framework web.(e.g. Struts, Spring MVC, JSF)

E outra… o básico para se evoluir é saber escutar os mais experientes, se as vezes dão puxões de orelha pode ter certeza que são para o seu bem, digo isso por experiência própria.

para fazer os posts em si, eu faria um Factory de posts…

mas você não vai resolver seus problemas em sistemas grandes com um pattern só.

enfim, nem li os posts de todo mundo aí, mas concordo com o Luca, quando ele diz que se você não sabe qual pattern usar, não sabe o suficiente sobre eles. Então estude.

boa sorte com seu projeto.

[]'s

Vini

Olá, agradeço pela resposta e por ter movida para Arquitetura de Sistemas.

Sim eu coloquei errado sobre MVC ser um padrão do GOF, peço desculpas para o pessoal! é um padrão de arquitetura como disse.

Talvez o pessoal não tinha entendido minha pergunta, mas tive boas respostas mesmo que as respostas ficaram equivocadas!

Bem, eu não tinha feito o Diagrama de Classes porque nos tinhas o Caso de Uso que acabei descrevendo ele.

Essa missão da equipe era realmente tentar aplicar modelos sobre um problema proposto:

O sistema Fórum de Discussões permite que questões sejam postadas e permite que várias respostas sejam anexadas a cada questão. O diagrama acima identifica os casos de uso previstos para o software.
Qualquer usuário assume o mesmo papel ao utilizar o sistema por tanto todas as funcionalidades estarão disponíveis para qualquer usuário do sistema.
Como se trata de um sistema cujo foco é a modelagem e não efetivamente sua usabilidade, foram descartados aspectos importantes como persistência (armazenamento em disco) das informações entre outras tantas possíveis funcionalidades aderentes ao projeto.

Então no final utilizamos o padrão MVC, com análise do problema e com isso alguns Pattern, só para ver como ficou:

Bem, e como ficou até agora, temos também as classes de domínio de aplicações e mais coisas.

---

O problema foi o seguinte, quando acabaram de me passar o caso, eu coloquei no Forum logo depois de dar uma análisada e o problema era aonde começar!
Os colegas disseram: começar pelo código, fazer as classes(modelar o sistema) e tal, e o que eu estava esperando era alguém dizer alguma proposta sobre padrões e frameworks, então vi e assumo que coloquei no forum errado, mas mesmo assim o pessoal tentou ajudar e no final saiu uma discussão sobre conceitos.

Nunca estive confuso, além disso eu nunca iria colocar no Forum uma pergunta que não teria resposta correta ou que satisfatória. No curso de Design Pattern que tivemos(eu e alguns colegas), o professor pedia para dizer um problema e ele dizia qual pattern poderia solucionar, mas em uma sistema as coisas vão ficando maiores e os pattern e diversas soluções podem surgir. Então, para um arquiteto ou alguém que usa padrões e conhece bem arquitetura iria dizer que o MVC seria uma solução, porém acho que seria legau eu ter colocado meus modelos aqui de Pattern, mesmo errados! assim o pessoal tinha uma visão melhor do que se passava o problema.

Agora talvez com esse MVC o pessoal irá ter uma noção melhor e se ficarem interessados colocarei o resto da solução por ser um assunto “avançado” em minha opinião.
porém que interessa a todos e também quem esta iniciado.

Sim, sim, estavamos todos confusos, apenas você que não estava… Anyway, nevermind…

Mas então, dá exemplos de como e porque você está utilizando, sei lá, FrontController, Bridge, Active Record por exemplo… Acho que vai esclarecer melhor a galera.

[]'s

zolotareff:

.
.
.
Agora talvez com esse MVC o pessoal irá ter uma noção melhor e se ficarem interessados colocarei o resto da solução por ser um assunto “avançado” em minha opinião.
porém que interessa a todos e também quem esta iniciado.

@zolotareff,
(Desculpe ressuscitar sua thread.)
Mas, postei apenas p/ te indicar a leitura de 1 livro simplemente formidável: Head First Design Patterns
Na verdade, eu tb comecei a lê-lo e posso te dizer q nos surpreendemos a ter 1 insight atrás do outro. Descobri tb q existe Padrões (na minha opinião) q se encaixão + para Modelagem (de (Classes) Entidades de Negócio, p/ ex.) do q para Projeto (de Sistemas)/design (tb não quero dizer q não possa ser usado p/ solucionar problemas de Projeto.) 1 ex. dele é Pattern ‘Strategy’!!
O livro, além de ter 1 ótimo senso de humor, é muito bom mesmo!! Ah, e tem 1 didática incrível!!

Com ele vc vai descobrir os “Princípios por trás dos Padrões”. Os próprios autores falam q os Patterns não “são inventados”; eles “são descobertos”! Então, quando vc estiver fazendo o design da sua Aplicação, vc(s) mesmo(s) vão sacar os Patterns bem no momento q se depararem com os problemas e, aí, v6 mesmos saberão aplicar os Patterns (cada 1) no cenário ideal/adequado. 8)
Espero ter contribuido,

Derlon

Isso tá com cara de trabalho de faculdade, não cheguei a ler todos posts do criador do tópico. Mas o problema maior ai é a falta de entendimento correto do que são e para que servem os Design Patterns, inclusive essa falta de conhecimento atinge profundamente essa cambada de professores de faculdade que nunca programaram de verdade na vida.

Os Design Patterns foram criados para resolver problemas conhecidos em desenvolvimento de software. Como vc já deve ter lido em algum lugar quanto a definição dos DP, são soluções reutilizáveis, para problemas específicos, etc, etc e etc…

Por serem soluções “plugáveis” em quase todos os sistemas, é meio que óbvio que resolve um problema X, mas não todo o seu sistema. DP não são códigos de inteligência artificial.

A base do seu software, e o sucesso dele, surgirão de uma boa modelagem de dados e lógica de programação, assim como conhecimento dos recursos da linguagem que estará utilizando.

Se você pegar as 500 matérias de design patterns que saem nas revistas java magazine, mundo java, .net magazine, etc…você verá 9 de cada 10 autores do artigo, mencionando algo mais ou menos assim em algum lugar da matéria:

“Atenção: Design Patterns são soluções criadas para resolver problemas. Se você ainda não tem um problema e quer usar design patterns, ai você terá um problema”.

E eu concordo plenamente pois já vi isso na prática.

Se o seu professor obrigou a usar DP na criação de um sistema, olha, tirando uma situação x ou y que ele queira abordar na didática, eu diria que ele é um desses que citei ali em cima.