O que é Design Pattern?

http://www.google.com.br/#q=Design+Patterns

:roll:

Problema universal.

Imagine os problemas que quase muitos projetos terão, logo existem soluções comuns

São metodologias pra desenvolvimento, vamo colocar como se fosse uma receita de bolo, mas você pode fazer um bolo com calda de chocolate entendeu/

Então, apenas finalizando o que o Anderson S. disse, com os problemas comuns forão reunidas as melhores ideias e formaram então padrões de soluções de design (design patteners)…

Thiago MuiLoko:

Então, apenas finalizando o que o Anderson S. disse, com os problemas comuns forão reunidas as melhores ideias e formaram então padrões de soluções de design (design patteners)…

quis dizer o lelodois aquele burro?

Em suma, são padrões que podem ser aplicados em determinadas situações corriqueiras em projetos de software, principalmente os corporativos (que em geral são grandes e possuem muitos requisitos, funcionais e não funcionais). Não são uma obrigação e nem vale a pena tentar ficar achando um jeito de meter um pattern no seu projeto. É uma biblioteca de boas práticas que você deve utilizar quando julgar que aquilo vai ajudar e não adicionar mais complexidade ainda ao seu sistema.

Por exemplo, o padrão Façade (fachada mesmo), falando bem por cima, é um cara que encapsula uma classe/um componente/um subsistema mais complexo e com muita lógica de negócio intrínseca, provendo uma interface mais fácil para sua utilização, apenas com métodos de interface bem definida, que realmente o cliente entenda. Por exemplo, há diversas classes do AWT que são coisa de ET, computação gráfica hardcore. Pra lidar diretamente com essas classes, tem que gostar e mesmo manjar de comp graf. Mas se eu quero apenas fazer uma telinha simples, preciso entender de RGB e afins? Creio que não. Posso fazer uma classe façade, me de metodos faceis do tipo criarBotaoPadrao e tenho meu botão ao inves de chamar n metodos e passar mais n parametros que por muitas vezes não sei para que servem e nem vou ver resultado deles, a não ser que eu saiba bem o que esteja fazendo. Em suma, meu façade irá desacoplar meu cliente de todas as classes mais complexas, criando um ponto único de acoplamento (Cliente – Façade – Classes/Subsistema complexo), além de prover uma interface simples. Em diversos casos, é um bom padrão a se utilizar.

De resto, faça como nosso amigo disse: procure no google. Tem um bom tutorial introdutório aqui: http://www.pg.cefetpr.br/coinf/simone/patterns/

Gostei dos links, e tiver como vocês me fornecerem tutorias com exemplos na prática ficarei grato!!

eu considero um otimo ponto de partida esse link

depois alguns livros para aprofundamento do assunto.

Eu vou responder o que não é design pattern.

Design Pattern não é double rainbow. Não é porque os mais pro recomendam, que você deve babar ovo.

Design Pattern não significa melhores práticas. Ao contrário, significa práticas comuns, ou seja, em boa parte das vezes o pattern é um jeito de resolver determinado problema, outras vezes, não, tudo depende de um contexto.

Design Pattern não é gerencial. Não se deve impor patterns, nem impregná-los em ferramentas dos gerentes (vide as famigeradas tarefas no Project com nomes Blablablá - DAO).

Finalizando, se você quer aprender Design Patterns leia o livro do GoF, ponto! Não há desculpa satisfatória pra não lê-lo, pois é de fundamental importância pra um programador.

Leonardo3001:

Eu vou responder o que não é design pattern.

Design Pattern não é double rainbow. Não é porque os mais pro recomendam, que você deve babar ovo.

Design Pattern não significa melhores práticas. Ao contrário, significa práticas comuns, ou seja, em boa parte das vezes o pattern é um jeito de resolver determinado problema, outras vezes, não, tudo depende de um contexto.

Design Pattern não é gerencial. Não se deve impor patterns, nem impregná-los em ferramentas dos gerentes (vide as famigeradas tarefas no Project com nomes Blablablá - DAO).

Finalizando, se você quer aprender Design Patterns leia o livro do GoF, ponto! Não há desculpa satisfatória pra não lê-lo, pois é de fundamental importância pra um programador.

oi,

Pois é, como falaram: não saia por ai aplicando DP em qualquer lugar só porque alguém te disse que era legal

Faça o simples (KISS) e então quando sentir a necessidade (Refatore) para usar um DP.

[]´s

Um… não. O livro é de papel, daqueles que se compra em livraria. Passar o link seria piratear. Acredito que se você quer mesmo fazer isso, você sabe os meios para se obter.

O livro se chama “Padrões de Projeto” em português, e “Design Patterns” em inglês. Não tem erro.

Anderson S.:

Leonardo3001:

Eu vou responder o que não é design pattern.

Design Pattern não é double rainbow. Não é porque os mais pro recomendam, que você deve babar ovo.

Design Pattern não significa melhores práticas. Ao contrário, significa práticas comuns, ou seja, em boa parte das vezes o pattern é um jeito de resolver determinado problema, outras vezes, não, tudo depende de um contexto.

Design Pattern não é gerencial. Não se deve impor patterns, nem impregná-los em ferramentas dos gerentes (vide as famigeradas tarefas no Project com nomes Blablablá - DAO).

Finalizando, se você quer aprender Design Patterns leia o livro do GoF, ponto! Não há desculpa satisfatória pra não lê-lo, pois é de fundamental importância pra um programador.

Você poderia me disponabilizar um link com esse livro??

Padrões de Projeto - Soluções Reutilizaveis de Software Orientado a Objetos