.NET - Design Patterns - Identificando e aplicando padrões
Antes de iniciar falando de padrões de projetos vamos falar da base que deu origem aos mesmos. Vamos falar um pouco sobre os princípios de design ou projeto de software conhecidos também como boas práticas no desenvolvimento de software |
Quais são os princípios de projeto de software ?
Princípios de projeto ou design de software representam um conjunto de diretrizes que nos ajudam a evitar que tenhamos um projeto ruim. Os princípios de design estão associados a Robert Martin, que agrupou essa informação em "Desenvolvimento Ágil de Software: Princípios, Padrões e Práticas".
De acordo com Robert Martin há três características importantes de um projeto ruim que devem ser evitadas :
Os princípios de um projeto de softwaren formam as bases sob as quais os padrões de projeto foram construídos. Eles são mais fundamentais que os padrões de projeto.
Toda vez que você seguir os princípios de projeto sua base de código vai torna-se mais flexível e adaptável a mudanças, bem como mais fácil de ser mantida. Vamos introduzir brevemente alguns dos princípios de concepção de software mais amplamente conhecidos e uma série de princípios conhecidos como o princípios S.O.L.I.D.
Princípios de projeto de software |
Existe uma série de princípios comuns de projeto que, assim como os padrões de projeto, tornaram-se as melhores práticas ao longo dos anos e ajudou a formar uma base sobre a qual a criação e manutenção de software pode ser construída. Vejamos os princípios mais importantes:
Keep It Simple Stupid (KISS )
Keep It Simple é um princípio geral que valoriza a simplicidade do projeto e defende que toda a complexidade desnecessária seja descartada. Assim este princípio nos guia a manter as coisas simples.
Dont Repeat Yourself (DRY)
O princípio DRY visa evitar a repetição de qualquer parte de um sistema, abstraindo as coisas que são comuns e colocando-as em um único local. Este princípio não se preocupa apenas com código, mas com qualquer lógica que esteja duplicada em um sistema, em última análise deve existir apenas uma representação para cada pedaço de conhecimento em um sistema. Em suma o princípio busca reduzir a duplicação de código e os problemas de manutenção resultantes.
Tell, Dont Ask
O princípio Tell, Don´t ASK (Diga, não pergunte) está estreitamente alinhado com o encapsulamento e a atribuição de responsabilidades às suas classes. O princípio afirma que você deve dizer aos objetos quais ações você deseja que eles realizem , em vez de realizar perguntas sobre o estado de um objeto e depois fazer uma decisão-se sobre a ação que você deseja realizar. Isso ajuda a alinhar as responsabilidades e evitar forte acoplamento entre as classes.
You Aint Gonna Need It (YAGNI )
O princípio YAGNI refere-se à necessidade de incluir apenas a funcionalidade que é necessária para a aplicação e adiar qualquer tentação de adicionar outros recursos que você pode pensar que você precisa. A metodologia de projeto que adere ao YAGNI é o desenvolvimento orientado a testes (TDD). O TDD versa sobre a escrever primeiro os testes que comprovam a funcionalidade de um sistema e em seguida, escrever apenas o código para obter o teste.
Separation of Concerns (SoC) - Separação das responsabilidades
O princípio SoC é o processo de dissecação de um pedaço de software em características distintas que encapsulam comportamento único e dados que podem ser utilizados por outras classes. Geralmente uma responsabilidade representa uma característica ou o comportamento de uma classe. O ato de separar um programa em responsabilidades discretas aumenta significativamente a reutilização de código, manutenção e testabilidade.
Princípios de projeto S.O.L.I.D |
Os princípios SOLID para programação e projeto orientados a objeto são de autoria de Robert C. Martin (mais conhecido como Uncle Bob) e datam do início de 2000.
A palavra SOLID é um acróstico onde cada letra significa a sigla de um princípio: SRP, OCP, LSP, ISP e DIP.
Obs: Os acrósticos são formas textuais onde a primeira letra de cada frase ou verso formam uma palavra ou frase
Na tabela abaixo vemos cada sigla, o seu significado e um resumo do princípio a que se refere no original e em uma tradução livre.
SRP | The Single
Responsibility Principle Principio da Responsabilidade Única |
Uma classe deve ter um,
e somente um, motivo para mudar. A class should have one, and only one, reason to change. |
OCP | The Open Closed
Principle Princípio Aberto-Fechado |
Você deve ser capaz de
estender um comportamento de uma classe, sem
modificá-lo. You should be able to extend a classes behavior, without modifying it. |
LSP | The Liskov Substitution
Principle Princípio da Substituição de Liskov |
As classes derivadas devem
ser substituíveis por suas classes base. Derived classes must be substitutable for their base classes. |
ISP | The Interface
Segregation Principle Princípio da Segregação da Interface |
Muitas interfaces
específicas são melhores do que uma interface geral Make fine grained interfaces that are client specific. |
DIP | The Dependency Inversion
Principle Princípio da inversão da dependência |
Dependa de uma
abstração e não de uma implementação. Depend on abstractions, not on concretions. |
Os princípios SOLID devem ser aplicados no desenvolvimento de software de forma que o software produzido tenha as seguintes características:
Dependency Inversion Principle (DIP) - O princípio da inversão de dependência (DIP)
O princípio DIP versa sobre como isolar suas classes de implementações concretas e fazendo-as depender de classes abstratas ou interfaces. Ele promove o mantra de codificar para uma interface ao invés de para uma implementação, o que aumenta a flexibilidade dentro de um sistema garantindo que o mesmo não está fortemente acoplado a um implementação.
Dependency Injection (DI) and Inversion of Control (IoC) - Injeção de dependência e Inversão de Controle
Intimamente ligados ao principio DIP temos os princípio DI e o princípio IoC.
O principio DI é o ato de fornecer um baixo nível ou classe dependente através de um construtor, método ou propriedade. Utilizado em conjunto com DI, estas classes dependentes podem ser invertidas para interfaces ou classes abstratas que levarão a sistemas com um baixo acoplamento altamente testáveis e de fácil manutenção. Assim a DI isola a implementação de um objeto da construção do objeto do qual ele depende.
No principio IoC, o fluxo de um sistema de controle é invertido em relação à programação procedural. Como exemplo podemos citar um recipiente IoC, cujo objetivo é injetar serviços no código de cliente sem que o código do cliente tenha especificado a implementação concreta.
Padrões de Projetos |
Depois de apresentar os princípios de projeto e os princípios SOLID vamos falar dos padrões de projeto.
Os Padrões de projetos são modelos de soluções abstratas de alto nível. Pense neles como modelos para soluções e não como soluções em si mesmo.
Infelizmente não existe nenhum framework que aplique de forma automática os padrões de projetos à sua aplicação, ao invés disso você normalmente faz isso refatorando o seu código e generalizando o seu problema e não abrindo um manual de receitas e copiando soluções.
Os padrões de projeto não são a panaceia universal ou a bala de prata que vai resolver tudo para você. Você tem que compreender plenamente o seu problema, generalizá-lo, e em seguida, aplicar um padrão que se ajuste ao seu cenário. No entanto, nem todos os problemas requerem um padrão de projeto. É verdade que os padrões de projeto podem ajudar a tornar simples problemas complexos mas eles também podem tornar complexos problemas simples.
Muitos desenvolvedores após lerem um livro de padrões, caem na armadilha de tentar aplicar padrões para tudo que estão fazendo, conseguindo exatamente o oposto do que os padrões se propõem : fazer as coisas simples.
Não existe mágica, a melhor maneira de aplicar padrões é identificar o problema fundamental que você está tentando resolver e procurar uma solução que se encaixa ao seu problema levando em conta o seu cenário que pode ser uma aplicação web, desktop, com acesso a dados, etc.
Repito mais uma vez : você não esta obrigado a usar os padrões de projeto em todos os seus projetos. Se você chegou a uma solução para um problema que é simples, clara e de fácil manutenção, mas ela não se encaixa em nenhum dos 23 padrões de projeto catalogados, não se apavore, você fez a coisa certa. Se você seguir outro caminho, apenas por modismo, isso vai complicar o seu projeto.
Eu sei que apesar de todo o conhecimento que se pode ter de Padrões de Projeto sempre fica aquela dúvida:
Como escolher e como aplicar um padrão de projeto ?
Bem, não existe uma receita pronta mas podemos facilitar a nossa decisão seguindo alguns conselhos.
Você pode escolher dentre muitos padrões de projetos já existentes e catalogados. Como então identificar aquele que é mais apropriado para o seu problema ?
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:
Estes são alguns conselhos práticos que podem ajudar você a melhor compreender como usar e aplicar os padrões de projeto mas existe um caminho mais adequado: sujar as mãos.
Na segunda parte deste artigo eu vou mostrar um exemplo prático de como podemos identificar e aplicar padrões de projetos usando um cenário básico de um situação real.
João 6:44 Ninguém pode vir a mim, se o Pai que me enviou não o trouxer; e eu o ressuscitarei no último dia.
Referências: