Design patterns (padres de projeto) surgiram com a motivao de ajudar a solucionar problemas que ocorrem frequentemente, e, se usados com bom senso, podem se tornar ferramentas poderosas para qualquer desenvolvedor de software, uma vez que j foram testadas, utilizadas e aprimoradas a partir da experincia e conhecimento de outros programadores. Preparamos um post explicando o que so design patterns e seus princpios comuns, baseado no livro Professional ASP.NET Design Patterns de Scott Millett.
Tirinha retirada do site Vida de Programador, um blog que publica tirinhas dirias com histrias engraadas e verdicas sobre o dia-a-dia de um programador. Explicando Design Patterns Design patterns (Padres de projeto) so solues de templates abstratas de alto nvel. Pense nelas como um blueprint (desenho tcnico ou documentao de uma arquitetura, etc.) para solues e no como uma soluo por si prpria. Voc no achar um framework que voc poder simplesmente aplicar para a sua aplicao; ao invs disso, voc chegar ao design patterns atravs da refatorao do seu cdigo e generalizao do seu problema. Design patterns no so somente aplicados em desenvolvimento de software; design patterns podem ser encontrados em diversas reas da vida, da engenharia at da arquitetura. Em fato, foi o arquiteto Christopher Alexander que introduziu a ideia de patterns em 1970 para construir um vocabulrio comum para discusses sobre design. Ele escreveu: Cada pattern descreve um problema que ocorre vrias vezes ao nosso redor e com isso, descrevem a soluo para o problema de uma maneira que voc pode usar essa soluo diversas vezes sem ter que fazer a mesma coisa duas ou mais vezes. Origem As origens do design patterns que prevalecem hoje na arquitetura de software nasceram das experincias e conhecimento dos programadores utilizando a programao orientada a objeto. O conjunto dos mais conhecidos design patterns esto catalogados no livro chamado Design Patterns: Elements of Reusable Object-Oriented Software, mais conhecido como Design Patterns Bible. Esse livro foi escrito por Erich Hamma, Richard Helm, Ralph Johson e John Vlissdes, mais conhecidos como Gang of Four. Eles coletaram 23 design patterns e organizaram em 3 grupos: Creational Patterns (Padres de Criao): Tratam da construo do objeto e o de referncia; Structural Patterns (Padres Estruturais): Tratam da relao entre objetos e como eles interagem entre sim para formarem grandes objetos complexos; Behavioral Patterns (Padres Comportamentais): Tratam da comunicao entre os objetos, especialmente em termos de responsabilidade e de algoritimos. Utilidade O valor dos design patterns reside no fato que eles so solues que foram utilizadas e testadas, o que nos d confiana em sua eficcia. Design patterns focam na reutilizao de solues. Todos os problemas no so iguais, mas se voc puder quebrar o problema e achar similiaridades com problemas que voc j resolveu antes, voc pode aplicar essas solues. Depois de dcadas de programao orientada a objeto, a maioria dos problemas que voc encontrar j tero sido resolvidas no passado, e haver um pattern disponvel para ajudar voc na implementao da soluo. Mesmo se voc acredita que o seu problema nico, ao quebr-lo em pequenas partes, voc ser capaz de generaliz-lo o suficiente para encontrar a soluo apropriada. O nome dos design patterns so teis porque refletem o seu comportamento e propsito, e fornecem um vocabulrio comum em um brainstorming de soluo. muito mais fcil falarmos em termos do nome do pattern do que detalhar sobre como essa implementao deveria funcionar. O que eles no so Design patterns no so a bala de prata (soluo de todos os problemas). Voc deve ter o entendimento geral do seu problema, generaliz-lo e ento aplicar o pattern apropriado para a soluo desse problema. Porm, nem todos os problemas requerem um design pattern. verdade que o design pattern pode ajudar a tornar problemas complexos em problemas simples, porm eles tambm podem tornar problemas simples em problemas complexos. Princpios comuns de design H diversos princpios comuns de design, que, assim como os design patterns, se tornaram boas prticas atravs dos anos e ajudaram a formar uma fundao no qual o nvel empresarial e software de fcil manuteno podem ser construdos. Abaixo, segue um resumo dos princpios mais conhecidos: Keep It Simple Stupid (KISS) Mantenha Isto Estupidamente Simples Um problema comum em programao de software a necessidade de complicar demais a soluo. O objetivo do princpio KISS manter o cdigo simples, mas no simplista, assim evitando complexidade desnecessria. Dont Repeat Yourself (DRY) No Repita Voc Mesmo O princpio do DRY evitar a repetio de qualquer parte do sistema abstraindo as coisas que so comuns entre si e coloc-las em um lugar nico. Esse princpio no se preocupa somente com o cdigo, mas qualquer lgica que est duplicada no sistema. Tell, Dont Ask Fale, no pergunte O principio Tell, Dont Ask est estreitamente alinhado com o encapsulamento e a atribuio de responsabilidades para as suas classes corretas. O princpio afirma que voc deve dizer aos objetos quais aes voc quer que eles realizem, ao invs de fazer perguntas sobre o estado do objeto e ento tomar uma deciso por si prprio em cima da ao que voc quer realizar. Isso ajuda a alinhar as responsabilidades e evitar o forte acoplamento entre as classes. You Aint Gonna Need It (YAGNI) Voc No Vai precisar Disso O princpio YAGNI se refere a necessidade de adicionar somente as funcionalidades que so necessrias para a aplicao e deixar de lado qualquer tentao de adicionar outras funcionalidades que voc acha que precisa. A metodologia de projeto que adere ao YAGNI a test-driven development (TDD) desenvolvimento orientado a testes. TDD se baseia na escrita de testes que comprovam a funcionalidade do sistema e ento escrevem somente o codigo para obter xito no teste. Separation Of Concerns (SoC) Separao de Responsabilidades SoC o processo de dissecao de uma parte de software em distintas caractersticas que encapsulam um nico comportamento e dados que podem ser utilizados por outras classes. Geralmente, a responsabilidade representa uma caractersticas ou comportamento da classe. O ato de separar um programa em discretas responsabilidades aumenta significativamente a reutilizao de cdigo, manuteno e testabilidade.