Padrões de projeto são comumente definidos como soluções já testadas para problemas recorrentes de design. Padrões de projeto têm suas raízes no trabalho de Christopher Alexander, um engenheiro civil, que escreveu sobre sua experiência na resolução de problemas de design e como eles se relacionam com os edifícios e cidades. Ocorreu a Alexander que certas construções de design, quando eventualmente era usado, levava ao efeito desejado. Ele documentou e publicou a sua experiência para que outras pessoas pudessem se beneficiar. Os profissionais de software passaram a incorporar princípios de Alexander para a criação e documentação de padrão de design.
Os Design Patterns (Padrão de projeto) são uma coleção de padrões de design de software, que são soluções para problemas conhecidos e recorrentes no desenvolvimento de software. Um Pattern descreve uma solução comprovada para um problema de design recorrente. Patterns são dispositivos que permitem que os programas compartilhem conhecimento sobre o seu design. Quando programamos, nós encontramos muitos problemas que ocorrem, ocorreram e irão ocorrer novamente. A questão que nos perguntamos agora é como nós vamos solucionar este problema desta vez? Documentar um padrão (pattern) é uma maneira de você poder reusar e possivelmente compartilhar informação que você aprendeu sobre a melhor maneira de se resolver um problema de design de software.
PORQUE USAR OS PATTERNS?
- Porque eles foram provados. Os padrões refletem a experiência, conhecimento e soluções dos desenvolvedores que tiveram sucesso usando esses padrões em seus trabalhos.
- São reusáveis. Os padrões provêem uma solução pronta que pode ser aplicada à diferentes problemas.
- São expressíveis. Os padrões provêem um vocabulário comum de soluções que podem expressar muitas soluções, sucintamente. É importante lembrar que os padrões, por si só, não garantem o sucesso do seu uso. A descrição do padrão indica quando ele pode ser aplicado, mas apenas a experiência pode proporcionar o entendimento de quando um padrão particular irá melhorar o design do sistema.
Tipo de padrão
Eles podem ser de criação (Creational Patterns), de estrutura e de comportamento. Por exemplo: se preciso adotar um padrão para criação de objetos, terei que olhar para os padrões existentes em “padrões de criação”.
- Creational Patterns
Todos os padrões criacionais (Creational) lidam com a melhor forma de se criar instâncias dos objetos. Isto é importante porque seu programa não deveria depender de como os objetos são criados e arranjados.
- Factory Method
Este é um tipo bem comum de padrão utilizado nos programas orientados ao objeto. O padrão Factory Method é caracterizado por retornar uma instância dentre muitas possíveis classes, dependendo dos dados providos a ele. Geralmente, todas as classes que ele retorna têm uma classe pai e métodos em comum, mas cada um executa tarefas diferentes e é otimizado para diferentes tipos de dados.
- Abstract Factory Method
O padrão Abstract Factory está a um nível de abstração maior do que o padrão Factory Method. Você pode usar este padrão quando deseja retornar uma das muitas classes de objetos relacionadas, cada qual pode retornar diferentes objetos se requisitado. Em outras palavras, o padrão Abstract Factory é uma fábrica de objetos que retorna uma das várias fábricas.
- Singleton
O padrão Singleton assegura que apenas uma única instância daquela classe vai existir. Por exemplo, seu sistema pode ter apenas um gerenciador de janelas, ou gerenciador de impressão, ou então um único ponto de acesso ao banco de dados.
- Builder
O padrão Builder constrói um número de objetos, como telas, de vários modos, dependendo dos dados.
O padrão Builder é algo como o Abstract Factory, na qual ambos retornam um número de métodos e objetos. A principal diferença é que enquanto o Abstract Factory retorna uma família de classes relacionadas, o Builder constrói um objeto complexo passo-a-passo, dependendo dos parâmetros passados a ele.
Nenhum comentário:
Postar um comentário