0

Design Patterns - C#

Ricardo Shikata
Ricardo Shikata

Quando você pode esperar receber uma pergunta sobre padrões de projeto? Você provavelmente obterá esses tipos de perguntas se estiver programando em C# de alto nível, mas também poderá obter perguntas sobre o padrão de design se o trabalho exigir que você programe em outras linguagens orientadas a objetos, incluindo Java, Python e Ruby. 

 

OOP (Object-Oriented Programming)

 

OOP é um modelo de programação que supostamente combina estrutura (dados) e comportamento (métodos) para fornecer funcionalidades de software. O mesmo foi um contraste acentuado em relação ao modelo de programação processual, que estava principalmente em voga quando o modelo OOP ganhou proeminência. A principal unidade de composição em um modelo de programação processual é um procedimento (principalmente uma função com efeitos colaterais). Os dados são alimentados em uma série de procedimentos que constituem o processo ou algoritmo em um contexto de solução. No caso do OOP, os dados e funções relacionadas são representados juntos como uma classe, que atua como uma unidade fundamental no modelo de programação. Esquematicamente temos a representação demonstrada.


class Teste

{

   //Variáveis Estáticas(Nível de Classe)

   //Variáveis de Instância(Nível de Objeto)

   //Métodos Privados

   //Métodos Públicos

}


Como programador, podemos criar muitas instâncias de uma classe durante a execução de um programa. Uma vez que a classe encapsula dados e suas operações associadas para fornecer uma entidade coerente, os problemas (ou, em vez disso, efeitos colaterais) associados a variáveis/dados globais (sendo usados como carga útil para os procedimentos) desapareceram de repente. Isso ajudou a gerenciar a complexidade do desenvolvimento de um grande software.


O OOP revolucionou a forma como os programadores modelaram o domínio do problema, com composições de classes alavancando encapsulamento, associação, herança e polimorfismo. Além disso, com a flexibilidade para modelar hierarquias (que representam de perto o domínio do problema) com facilidade, tornou-se natural que os desenvolvedores pensassem em termos de objetos.


A Microsoft inicialmente colocou suas apostas em uma estratégia de arquitetura corporativa chamada Windows DNA, centrada no DCOM (Distributed Component Object Model). O advento e a tração do modelo de programação Java forçaram a Microsoft a reformular sua estratégia, então eles decidiram criar uma plataforma de máquina virtual chamada .NET. A plataforma .NET foi lançada em 2002, e foi apelidada de Java da Microsoft. O velho adágio de “imitação é a forma mais sincera de lisonja” foi ecoada pelos especialistas da indústria.


Explicando Design Patterns


Compreendendo os princípios básicos Na programação, os padrões de projeto são soluções reutilizáveis ​​para problemas comuns de programação. Eles foram modelados de acordo com padrões de projeto em arquitetura - você sabe, o campo onde você constrói edifícios reais, não o termo do software. Um bom exemplo é um arco, que é um padrão arquitetônico comum usado para distribuir uma grande quantidade de peso em um vão. Você não precisa explicar todos os detalhes de um arco para os arquitetos - eles entendem o que é um arco assim que você diz a palavra. O mesmo é verdade quando os programadores dizem que estão usando um singleton em um aplicativo. Você deve saber que um singleton significa uma única instância de um objeto. 


Design patterns (Padrões de projeto) são soluções de templates abstratas de alto nível. Pense nelas como um “blueprint” (desenho técnico ou documentação de uma arquitetura, etc.) para soluções e não como uma solução por si própria. Você não achará um framework que você poderá simplesmente aplicar para a sua aplicação; ao invés disso, você chegará ao design patterns através da refatoração do seu código e generalização do seu problema.

 

Design patterns não são somente aplicados em desenvolvimento de software; design patterns podem ser encontrados em diversas áreas da vida, da engenharia até da arquitetura. De fato, foi o arquiteto Christopher Alexander que introduziu a ideia de patterns em 1970 para construir um vocabulário comum para discussões sobre design. Ele escreveu:

  

"Cada pattern descreve um problema que ocorre várias vezes ao nosso redor e com isso, descrevem a solução para o problema de uma maneira que você pode usar essa solução diversas vezes sem ter que fazer a mesma coisa duas ou mais vezes."


O arquiteto Christopher Alexander, em seus livros (1977/1979) Notes on the Synthesis of Form, The Timeless Way of Building e A Pattern Language, estabelece que um padrão deve ter, idealmente, as seguintes características:

  1. Encapsulamento: um padrão encapsula um problema ou solução bem definida. Ele deve ser independente, específico e formulado de maneira a ficar claro onde ele se aplica.
  2. Generalidade: todo padrão deve permitir a construção de outras realizações a partir deste padrão.
  3. Equilíbrio: quando um padrão é utilizado em uma aplicação, o equilíbrio dá a razão, relacionada com cada uma das restrições envolvidas, para cada passo do projeto. Uma análise racional que envolva uma abstração de dados empíricos, uma observação da aplicação de padrões em artefatos tradicionais, uma série convincente de exemplos e uma análise de soluções ruins ou fracassadas pode ser a forma de encontrar este equilíbrio.
  4. Abstração: os padrões representam abstrações da experiência empírica ou do conhecimento cotidiano.
  5. Abertura: um padrão deve permitir a sua extensão para níveis mais baixos de detalhe.
  6. Combinatoriedade: os padrões são relacionados hierarquicamente. Padrões de alto nível podem ser compostos ou relacionados com padrões que endereçam problemas de nível mais baixo.

 

Não pode ser considerado um padrão de projeto trecho de códigos específicos, mesmo que para o seu criador ele reflita um padrão, que soluciona um determinado problema, porque os padrões devem estar a um nível maior de abstração e não limitado a recursos de programação. Um padrão de projeto nomeia, abstrai e identifica os aspectos chaves de uma estrutura de projeto comum para torna-la útil para a criação de um projeto orientado a objetos reutilizável.


Utilidade

 

O valor dos designs patterns reside no fato que eles são soluções que foram utilizadas e testadas, o que nos dá confiança em sua eficácia. Design patterns focam na reutilização de soluções. Todos os problemas não são iguais, mas se você puder “quebrar” o problema e achar similiaridades com problemas que você já resolveu antes, você pode aplicar essas soluções. Depois de décadas de programação orientada a objeto, a maioria dos problemas que você encontrará já terão sido resolvidas no passado, e haverá um pattern disponível para ajudar você na implementação da solução. 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 solução apropriada.

 

O nome dos design patterns são úteis porque refletem o seu comportamento e propósito, e fornecem um vocabulário comum em um brainstorming de solução. É muito mais fácil falarmos em termos do nome do pattern do que detalhar sobre como essa implementação deveria funcionar.


O que eles não são

 

Design patterns não são a bala de prata (solução de todos os problemas). Você deve ter o entendimento geral do seu problema, generalizá-lo e então aplicar o pattern apropriado para a solução desse problema. Porém, nem todos os problemas requerem um design pattern.. É verdade que o design pattern pode ajudar a tornar problemas complexos em problemas simples, porém eles também podem tornar problemas simples em problemas complexos.

 

PRINCÍPIOS COMUNS DE DESIGN

 

Há diversos princípios comuns de design, que, assim como os design patterns, se tornaram boas práticas através dos anos e ajudaram a formar uma fundação no qual o nível empresarial e software de fácil manutenção podem ser construídos. Abaixo, segue um resumo dos princípios mais conhecidos:

 

Keep It Simple Stupid (KISS) - Mantenha Isto Estupidamente Simples

 

Um problema comum em programação de software é a necessidade de complicar demais a solução. O objetivo do princípio KISS é manter o código simples, mas não simplista, assim evitando complexidade desnecessária.

 

Don’t Repeat Yourself (DRY) - Não Repita Você Mesmo

 

O princípio do DRY é evitar a repetição de qualquer parte do sistema abstraindo as coisas que são comuns entre si e colocá-las em um lugar único. Esse princípio não se preocupa somente com o código, mas qualquer lógica que está duplicada no sistema.

 

Tell, Don’t Ask - Fale, não pergunte

 

O principio Tell, Don’t Ask está estreitamente alinhado com o encapsulamento e a atribuição de responsabilidades para as suas classes corretas. O princípio afirma que você deve dizer aos objetos quais ações você quer que eles realizem, ao invés de fazer perguntas sobre o estado do objeto e então tomar uma decisão por si próprio em cima da ação que você quer realizar. Isso ajuda a alinhar as responsabilidades e evitar o forte acoplamento entre as classes.

 

You Ain’t Gonna Need It (YAGNI) - Você Não Vai precisar Disso

 

O princípio YAGNI se refere a necessidade de adicionar somente as funcionalidades que são necessárias para a aplicação e deixar de lado qualquer tentação 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 então escrevem somente o codigo para obter êxito no teste.

 

Separation Of Concerns (SoC) - Separação de Responsabilidades

 

SoC é o processo de dissecação de uma parte de software em distintas características que encapsulam um único comportamento e dados que podem ser utilizados por outras classes. Geralmente, a responsabilidade representa uma características ou comportamento da classe. O ato de separar um programa em discretas responsabilidades aumenta significativamente a reutilização de código, manutenção e testabilidade.


0
4

Comentários (2)

1
M

Marcelo Mora

15/10/2021 14:50

Ricardo, obrigado por compartilhar.

Os assuntos relacionados há Design Patterns sempre são bem vindos.

1
Marcos Bruno

Marcos Bruno

15/10/2021 10:48

Bom dia!

Excelente material.

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

Brasil