none
Design Patterns RRS feed

  • Pergunta

  • Só pra inaugurar e tentar iniciar uma discussão nesse fórum, gostaria de saber de vocês, quais os designs patterns vocês já utilizaram em suas aplicações .net.

    Eles ajudaram ou atrapalharam ?? Se ajudaram, onde pode perceber esse ajuda ?? Na manutenção do código, produtividade, organização, etc.

    O que a adoção do design pattern atrapalhou ??

    Se for possível comentar um pouco sobre o pattern utilizado, bem como links de referências, acredito que possa contribuir ainda mais com o post.

    Um abraço

    André

    terça-feira, 16 de maio de 2006 04:42

Respostas

  • Bom, pra começar a discussão:

    Provavelmente, eu devo ter usado várias design patterns nas aplicações que eu desenvolvi e venho desenvolvendo. A questão é que talvez não tenha sido de maneira consciente (vou usar a pattern X, porque essa situação se aplica), visto que até pouco tempo atrás, por mais que eu tentasse ter em mente todas as design patterns e quando aplica-las, eu não conseguia. Isso porque não existem hoje referências realmente úteis sobre design patterns na internet e em livros: ou você considera francamente que exemplos de design patterns com animais de um zoologico um exemplo de vida real? Eu preciso um pouco mais que isso.

    Onde eu quero chegar com esse palavrório todo? Finalmente achei um livro, que recomendo a todos por conter o conteúdo de design patterns com exemplos mais reais, além de ser uma leitura divertida, daquelas que não dá sono na página 10. O Livro é "Head First Design Pattern". Pode procurar na Amazon, na Livraria Cultura, na Bookpool. etc.

    Bom, após ler esse livro, eu identifiquei pelo menos uma pattern que eu vinha usando no meu desenvolvimento: a Command Pattern. Essa pattern visa permitir que um objeto possa usar, com a mesma interface, n outros objetos, com objetivos totalmente diferentes, desde que os mesmos implementem a mesma interface. Eu estou usando essa interface como um canal de ligação entre minha camada de apresentação e a de negócios, para que as mesmas sejam totalmente desacopladas uma da outra. Como vantagem, eu percebi que algum código de negócio, que por vezes era implementado na camada de apresentação por ter um caráter mais visual, acabou migrando totalmente para a camada de negócio, deixando a interface totalmente "burra" por assim dizer. Outra questão é que posso trocar a camada de apresentação sem me preocupar com um possível acoplamento com business, como métodos de business que retornem algo específico de apresentação. Dá para se levar em consideração outro ponto: como a interface command acaba sendo o único ponto através do qual se solicita execução de métodos de negócio, ela é a única coisa que a apresentação precisa conhecer. O código fica altamente padronizado e simples.

    A principal desvantagem é a falta de intellisense na hora da programação.

    Bom, era isso que eu tinha pra compartilhar.

     

    terça-feira, 16 de maio de 2006 11:40
  • Um site legal sobre patterns, e usos mais "real world", pode ser encontrado em, http://www.dofactory.com/.

    Eles tem até um pacotão com vários exemplos que pode ser comprado.


    []´s
    sexta-feira, 19 de maio de 2006 18:19

Todas as Respostas

  • Bom, pra começar a discussão:

    Provavelmente, eu devo ter usado várias design patterns nas aplicações que eu desenvolvi e venho desenvolvendo. A questão é que talvez não tenha sido de maneira consciente (vou usar a pattern X, porque essa situação se aplica), visto que até pouco tempo atrás, por mais que eu tentasse ter em mente todas as design patterns e quando aplica-las, eu não conseguia. Isso porque não existem hoje referências realmente úteis sobre design patterns na internet e em livros: ou você considera francamente que exemplos de design patterns com animais de um zoologico um exemplo de vida real? Eu preciso um pouco mais que isso.

    Onde eu quero chegar com esse palavrório todo? Finalmente achei um livro, que recomendo a todos por conter o conteúdo de design patterns com exemplos mais reais, além de ser uma leitura divertida, daquelas que não dá sono na página 10. O Livro é "Head First Design Pattern". Pode procurar na Amazon, na Livraria Cultura, na Bookpool. etc.

    Bom, após ler esse livro, eu identifiquei pelo menos uma pattern que eu vinha usando no meu desenvolvimento: a Command Pattern. Essa pattern visa permitir que um objeto possa usar, com a mesma interface, n outros objetos, com objetivos totalmente diferentes, desde que os mesmos implementem a mesma interface. Eu estou usando essa interface como um canal de ligação entre minha camada de apresentação e a de negócios, para que as mesmas sejam totalmente desacopladas uma da outra. Como vantagem, eu percebi que algum código de negócio, que por vezes era implementado na camada de apresentação por ter um caráter mais visual, acabou migrando totalmente para a camada de negócio, deixando a interface totalmente "burra" por assim dizer. Outra questão é que posso trocar a camada de apresentação sem me preocupar com um possível acoplamento com business, como métodos de business que retornem algo específico de apresentação. Dá para se levar em consideração outro ponto: como a interface command acaba sendo o único ponto através do qual se solicita execução de métodos de negócio, ela é a única coisa que a apresentação precisa conhecer. O código fica altamente padronizado e simples.

    A principal desvantagem é a falta de intellisense na hora da programação.

    Bom, era isso que eu tinha pra compartilhar.

     

    terça-feira, 16 de maio de 2006 11:40
  • Um site legal sobre patterns, e usos mais "real world", pode ser encontrado em, http://www.dofactory.com/.

    Eles tem até um pacotão com vários exemplos que pode ser comprado.


    []´s
    sexta-feira, 19 de maio de 2006 18:19
  • Eu já usei o TransferObject, DataAccessObject e o FactoryDAO.

    Estes Patterns me ajudaram muito na separação da camada de acesso à dados e na independência de banco de dados já que implementa uma fábrica de DAO(FactoryDAO).

    Transfer Object - A classe é um espelho da tabela no BD e serve para transportar dados entre as camadas DAL(dados) e BLL(negócios)

    DAO - Classe que implementa todos os métodos CRUD(create, read, Up, Del) e envia um TO ou uma lista de TO para o solicitante. Fornece uma Interface comum à todos os BDs.

    FactoryDAO - Fabrica os DAOs, exemplo: ClienteSqlDAO ou ClienteMySqlDAO

    Para maiores informações

    http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html

    sexta-feira, 26 de maio de 2006 20:19
  • Claro que é útil! E até demais! :-D

    Quando você desenvolve sistemas pensando no futuro em questões como:
    Desenvolvimento de equipe, manutenção, legibilidade de código e etc os DP's são a melhor opção. Pensa comigo: Você tem soluções padrão (que todos deveriam conhecer) para problemas comuns (não precisa re-inventar a roda) e que estão mais do que testados.

    Vou dar um exemplo simples:
    Sabemos que temos o ConfigurationManager e o WebConfigurationManager. A Diferença básica é que o WebConfigurationManager dá acesso a algumas seções que só o WebConfig traz para você, então é mais indicado que o mesmo seja usado na Web;
    Então tinhamos um projeto que envolvia um workflow onde três tipos de clientes seriam utilizados: Mobile, Desktop e Web. Conforme prega o Pattern MVC, toda a regra de negócio ficou numa Class Library sendo assim a questão do ambiente de execução (mobile, web e desktop) se tornou uma questão de interface, porém como a class Library será usada por todos, como saber se devemos utilizar o WebConfigurationManager ou o ConfigurationManager? Já uqe se a class library for utilizada pela Web deverá chamar o WebConfiguration?

    A Solução foi usar o Pattern Factory: Criamos uma ConfigurationFactory que descobria se o ambiente em que estava sendo executada a aplicação era Web ou não, caso fosse Web buscavamos a informação requisitada dentro do WebConfigurationManager (de maneira que acessavamos as sessões que só o WebConfigurationManager traz), e caso não fosse Web utilizavamos o ConfigurationManager. Então todo o algoritmo de decisão de qual ConfigurationManager utilizar era executado a cada leitura de arquivo de configuração, porém de maneira transparente ao usuário...
    Um dia pensamos em fazer uma validação antes de enviar o resultado da leitura de arquivo de configuração. Implementamos a validação na nossa classe ConfigurationFactory e todo o projeto já estava adequado a nova regra de negócio...

    E tudo isso graças a uma simples Factory...

    Espero que a pressa ao escrever não tenha atrapalhado o entendimento do pessoal.

    Abraços...

    quarta-feira, 7 de junho de 2006 18:38
  •  Thiago Oliveira wrote:
    Um site legal sobre patterns, e usos mais "real world", pode ser encontrado em, http://www.dofactory.com/.

    Eles tem até um pacotão com vários exemplos que pode ser comprado.


    []´s

     

    Muito bom

    sexta-feira, 28 de julho de 2006 16:53