0

Design Patterns - C# (Parte 2)

Ricardo Shikata
Ricardo Shikata

Adaptado de:

http://www.macoratti.net/13/09/net_dp1.htm


SABER QUANDO USAR PADRÕES DE DESIGN


É importante conhecer os padrões de design, mas eles não são uma solução definitiva para todos os problemas de programação que você tem. É tentador simplesmente adicionar um padrão de design porque você acha que vai funcionar apenas para descobrir que a solução

  • É mais complexa do que você pensava que seria,
  • Coloca muito mais linhas de código do que outra solução e / ou
  • Faz com que o programa para de ser executado depois de compilado. 

Os padrões de projeto são blocos de construção. Assim como usávamos nossos dedos para contar e somar números quando éramos jovens, usar os dedos não funciona quando você está adicionando grandes números ou multiplicando números. Ao adicionar números grandes, você pode adicionar alguns números nos dedos quando a situação exigir. O mesmo é verdade quando você está programando-os padrões de design são as principais ferramentas que você aprende na programação e que pode usar quando puderem executar a função de que você precisa. 

Quando você for questionado sobre padrões de design, pode ser questionado apenas se você conhece alguns dos padrões de design comuns, o que eles fazem e se você pode fornecer exemplos de alguns deles e como eles trabalham. Linguagens modernas implementam muitos padrões de projeto diretamente em suas estruturas.  Para saber qual padrão de projeto você pode usar e como aplicar o modelo ao seu problema específico é importante compreender e utilizar alguns conceitos:

  1. Você não pode aplicar padrões sem conhecê-los bem. O primeiro passo a dar é expandir o seu conhecimento e estudar os padrões e princípios na forma concreta e abstrata. Você pode implementar padrões de projetos de muitas formas e quanto mais você conhecer sobre as diferentes implementações possíveis mais você irá compreender sobre o real objetivo do padrão e de como um padrão pode possuir diferentes implementações.
  2. Você precisa introduzir a complexidade de um padrão de projeto no seu aplicativo? É comum para os desenvolvedores tentar usar um padrão para resolver todos os problemas quando eles estão estudando padrões. Você sempre precisa parar e pesar o tempo inicial necessário para implementar um padrão e o benefício que isso vai dar. Lembre-se do princípio KISS: Keep It Simple, Stupid ou seja Mantenha as coisas simples.
  3. Generalize o seu problema, identifique os problemas que você está enfrentando de forma mais abstrata. Veja a forma como a intenção de cada padrão e princípio está escrito, e veja se o seu problema se encaixa com o problema que um determinado padrão ou princípio está tentando resolver. Lembre-se que padrões de projetos são soluções de alto nível, tente abstrair o seu problema, e não se concentre demais nos detalhes de seu problema específico.
  4. Olhe para os padrões de natureza semelhante e para os padrões no mesmo grupo. Só porque você utilizou um padrão antes não significa que ele será sempre a escolha correta quando for resolver um problema.
  5. Encapsule o que varia. Olhe para o que provavelmente vai mudar com a sua aplicação. Se você sabe que um algoritmo vai mudar ao longo do tempo, olhe para um padrão que vai ajudar você a alterá-lo sem afetar o resto de sua aplicação.
  6. Depois de ter escolhido um padrão de projeto, esteja certo em usar a linguagem de seu padrão ao longo com a linguagem do domínio ao nomear os participantes em uma solução. Por exemplo, se você está usando o padrão Strategy para fornecer uma solução procure utilizar nomes adequados usando um vocabulário padrão em comum com a linguagem de seu domínio, isso tornará o seu código mais legível e compreensível para outros desenvolvedores com conhecimento de padrões.
  7. Quando se trata de padrões de projeto, não há substituto para estudar. Quanto mais você saber sobre cada um dos padrões, melhor equipado você estará em aplicá-los. Procure captar a intenção de cada padrão para refrescar sua memória para quando você tiver um problema e estiver procurando uma solução.
  8. Um exercício de aprendizado é tentar identificar os padrões aplicados na plataforma .NET. Por exemplo, o recurso de cache no ASP.NET usa o padrão Singleton, a criação de um novo GUID usa o padrão Factory, as classes que tratam XML usam o padrão Factory, etc. Isso ajuda no seu entendimento de como aplicar os padrões.


Gangue dos Quatro (Gang of Four)

 

Os patterns de Alexander procuravam prover uma fonte de idéias provadas para indivíduos e comunidades para serem usadas em construções, mostrando assim o quanto belo, confortável e flexível os ambientes podem ser construídos. Em 1987, a partir dos conceitos criados por Alexander, os programadores Kent Beck e Ward Cunningham propuseram os primeiros padrões de projeto para a área da ciência da computação. Em um trabalho para a conferência OOPSLA, eles apresentaram alguns padrões para a construção de aplicações comerciais em linguagem Smalltalk. Nos anos seguintes Beck, Cunningham e outros seguiram com o desenvolvimento destas ideias.

 

Porém, o movimento ao redor de padrões de projeto só ganhou popularidade em 1995 quando as origens do design patterns que prevalecem hoje na arquitetura de software nasceram das experiências e conhecimento dos programadores utilizando a programação orientada a objeto. O conjunto dos mais conhecidos design patterns estão catalogados no livro chamado “Design Patterns: Elements of Reusable Object-Oriented Software”, mais conhecido como “Design Patterns Bible”. Este livro foi publicado pela Addison-Wesley em 1994 e é o primeiro livro publicado sobre padrões de projeto. Esse livro foi escrito por Erich Hamma, Richard Helm, Ralph Johson e John Vlissdes, mais conhecidos como a "Gangue dos Quatro" (Gang of Four) ou simplesmente "GoF". Eles coletaram 23 design patterns e organizaram em 3 grupos:

  • Creational Patterns (Padrões de Criação): Tratam da construção do objeto e o de referência; Os padrões de criação são aqueles que abstraem e/ou adiam o processo criação dos objetos. Eles ajudam a tornar um sistema independente de como seus objetos são criados, compostos e representados. Um padrão de criação de classe usa a herança para variar a classe que é instanciada, enquanto que um padrão de criação de objeto delegará a instanciação para outro objeto.


Os padrões de criação tornam-se importantes à medida que os sistemas evoluem no sentido de dependerem mais da composição de objetos do que a herança de classes. O desenvolvimento baseado na composição de objetos possibilita que os objetos sejam compostos sem a necessidade de expor o seu interior como acontece na herança de classe, o que possibilita a definição do comportamento dinamicamente e a ênfase desloca-se da codificação de maneira rígida de um conjunto fixo de comportamentos, para a definição de um conjunto menor de comportamentos que podem ser compostos em qualquer número para definir comportamentos mais complexos. Há dois temas recorrentes nesses padrões.

  1. Todos encapsulam conhecimento sobre quais classes concretas são usadas pelo sistema.
  2. Ocultam o modo como essas classes são criadas e montadas. Tudo que o sistema sabe no geral sobre os objetos é que suas classes são definidas por classes abstratas.

 

Conseqüentemente, os padrões de criação dão muita flexibilidade no que é criado, quem cria, como e quando é criado. Eles permitem configurar um sistema com objetos “produto” que variam amplamente em estrutura e funcionalidade. A configuração pode ser estática (isto é, especificada em tempo de compilação) ou dinâmica (em tempo de execução).


  • Structural Patterns (Padrões Estruturais): Tratam da relação entre objetos e como eles interagem entre sim para formarem grandes objetos complexos. Os de classes utilizam a herança para compor interfaces ou implementações, e os de objeto descrevem maneiras de compor objetos para obter novas funcionalidades. A flexibilidade obtida pela composição de objetos provém da capacidade de mudar a composição em tempo de execução o que não é possível com a composição estática (herança de classes).


  • Behavioral Patterns (Padrões Comportamentais): Tratam da comunicação entre os objetos, especialmente em termos de responsabilidade e de algoritmos. Eles não descrevem apenas padrões de objetos ou de classes, mas também os padrões de comunicação entre os objetos. Os padrões comportamentais de classes utilizam a herança para distribuir o comportamento entre classes, e os padrões de comportamento de objeto utilizam a composição de objetos em contrapartida a herança. Alguns descrevem como grupos de objetos que cooperam para a execução de uma tarefa que não poderia ser executada por um objeto sozinho.

 

Eles são difíceis de entender em parte porque há muitos padrões para lembrar: 23 deles, para ser exato. Felizmente, alguns padrões de design são mais importantes do que outros, e são esses padrões de design que você precisa saber. Muitas linguagens de programação modernas eliminaram a necessidade de muitos dos 23 padrões de design que existem.  


Abaixo algumas referências para quem quiser se aprofundar ou consultar mais sobre o assunto:


http://www.macoratti.net/Default.aspx


https://refactoring.guru/pt-br/design-patterns


https://www.dofactory.com/net/state-design-pattern


https://hillside.net/patterns/patterns-catalog


No meu Github tem os códigos de implementação em C# dos padrões GOF, para quem tiver interesse:


https://github.com/shyoutarou/DesignPatterns_GOF_Csharp


0
0

Comentários (0)

Give a star to Soluções dos desafios dos bootcamps: https://github.com/shyoutarou/desafios-DIO

Brasil