padrão de design de software

Na engenharia de software , um padrão de projeto de software é uma solução geral e reutilizável para um problema comum dentro de um determinado contexto no projeto de software . Não é um projeto acabado que pode ser transformado diretamente em código- fonte ou código de máquina . Em vez disso, é uma descrição ou modelo de como resolver um problema que pode ser usado em muitas situações diferentes. Os padrões de design são práticas recomendadas formalizadas que o programador pode usar para resolver problemas comuns ao projetar um aplicativo ou sistema.

Padrões de projeto orientados a objetos geralmente mostram relacionamentos e interações entre classes ou objetos , sem especificar as classes ou objetos finais do aplicativo envolvidos. Padrões que implicam estado mutável podem ser inadequados para linguagens de programação funcionais . Alguns padrões podem se tornar desnecessários em linguagens que possuem suporte embutido para resolver o problema que estão tentando resolver, e os padrões orientados a objetos não são necessariamente adequados para linguagens não orientadas a objetos.

Os padrões de projeto podem ser vistos como uma abordagem estruturada para a programação de computadores intermediária entre os níveis de um paradigma de programação e um algoritmo concreto .

História

Os padrões se originaram como um conceito arquitetônico de Christopher Alexander já em 1977 (cf. "The Pattern of Streets", JOURNAL OF THE AIP, setembro de 1977, vol. 32, nº 3, pp. 273–278). Em 1987, Kent Beck e Ward Cunningham começaram a experimentar a ideia de aplicar padrões à programação – especificamente linguagens de padrões – e apresentaram seus resultados na conferência da OOPSLA naquele ano. ^{[1] [2]} Nos anos seguintes, Beck, Cunningham e outros continuaram este trabalho.

Os padrões de projeto ganharam popularidade na ciência da computação depois que o livro Design Patterns: Elements of Reusable Object-Oriented Software foi publicado em 1994 pelo chamado "Gang of Four" (Gamma et al.), que é freqüentemente abreviado como "GoF". Nesse mesmo ano, foi realizada a primeira Conferência de Linguagens de Padrões de Programação e, no ano seguinte, o Repositório de Padrões de Portland foi criado para documentação de padrões de projeto. O escopo do termo permanece uma questão de disputa. Livros notáveis ​​no gênero padrão de design incluem:

• Gama, Erich ; Helm, Ricardo ; Johnson, Ralph ; Vlissides, John (1994). Padrões de Projeto: Elementos de Software Reutilizável Orientado a Objetos . Addison-Wesley . ISBN 978-0-201-63361-0.
• Brinch Hansen, Per (1995). Estudos em Ciência Computacional: Paradigmas de Programação Paralela . Prentice Hall. ISBN 978-0-13-439324-7.
• Buschmann, Frank ; Meunier, Regina; Rohnert, Hans; Sommerlad, Peter (1996). Arquitetura de Software Orientada a Padrões, Volume 1: Um Sistema de Padrões . John Wiley & Filhos. ISBN 978-0-471-95869-7.
• Beck, Kent (1997). Padrões de Melhores Práticas do Smalltalk . Prentice Hall. ISBN 978-0134769042.
• Schmidt, Douglas C .; Stall, Michael; Rohnert, Hans; Buschmann, Frank (2000). Arquitetura de Software Orientada a Padrões, Volume 2: Padrões para Objetos Simultâneos e em Rede . John Wiley & Filhos. ISBN 978-0-471-60695-6.
• Fowler, Martin (2002). Padrões de Arquitetura de Aplicativo Corporativo . Addison-Wesley . ISBN 978-0-321-12742-6.
• Hohpe, Gregor; Woolf, Bobby (2003). Padrões de Integração Corporativa: Projetando, Construindo e Implantando Soluções de Mensagens . Addison-Wesley . ISBN 978-0-321-20068-6.
• Freeman, Eric T.; Robson, Elisabeth; Bates, Bert; Serra, Kathy (2004). Use a Cabeça Padrões de Design . Mídia O'Reilly . ISBN 978-0-596-00712-6.

Embora os padrões de projeto tenham sido aplicados praticamente por um longo tempo, a formalização do conceito de padrões de projeto definhou por vários anos. ^[3]

Praticar

Os padrões de design podem acelerar o processo de desenvolvimento fornecendo paradigmas de desenvolvimento testados e comprovados. ^[4] O design de software eficaz requer a consideração de questões que podem não se tornar visíveis até mais tarde na implementação. O código recém-escrito geralmente pode ter problemas sutis ocultos que levam tempo para serem detectados, problemas que às vezes podem causar grandes problemas no futuro. A reutilização de padrões de projeto ajuda a evitar esses problemas sutis ^[5] e também melhora a legibilidade do código para codificadores e arquitetos familiarizados com os padrões.

Para obter flexibilidade, os padrões de projeto geralmente introduzem níveis adicionais de indireção , o que, em alguns casos, pode complicar os projetos resultantes e prejudicar o desempenho do aplicativo.

Por definição, um padrão deve ser programado novamente em cada aplicativo que o utiliza. Como alguns autores veem isso como um retrocesso em relação à reutilização de software fornecida pelos componentes , os pesquisadores trabalharam para transformar padrões em componentes. Meyer e Arnout foram capazes de fornecer componentização total ou parcial de dois terços dos padrões que tentaram. ^[6]

As técnicas de projeto de software são difíceis de aplicar a uma gama mais ampla de problemas. ^{[ carece de fontes ]} Padrões de projeto fornecem soluções gerais, documentadas em um formato que não requer detalhes vinculados a um problema específico.

Estrutura

Os padrões de projeto são compostos de várias seções (consulte § Documentação abaixo). De particular interesse são as seções Estrutura, Participantes e Colaboração. Estas seções descrevem um motivo de projeto : uma microarquitetura prototípica que os desenvolvedores copiam e adaptam a seus projetos particulares para resolver o problema recorrente descrito pelo padrão de projeto. Uma micro-arquitetura é um conjunto de constituintes do programa (por exemplo, classes, métodos...) e seus relacionamentos. Os desenvolvedores usam o padrão de design introduzindo em seus projetos essa microarquitetura prototípica, o que significa que as microarquiteturas em seus projetos terão estrutura e organização semelhantes ao motivo de design escolhido.

Padrões específicos de domínio

Esforços também foram feitos para codificar padrões de projeto em domínios específicos, incluindo o uso de padrões de projeto existentes, bem como padrões de projeto específicos de domínio. Os exemplos incluem padrões de design de interface do usuário , ^[7] visualização de informações , ^[8] design seguro, ^[9] "usabilidade segura", ^[10] Web design ^[11] e design de modelo de negócios. ^[12]

Os procedimentos anuais da conferência Pattern Languages ​​of Programming ^[13] incluem muitos exemplos de padrões específicos de domínio.

Classificação e lista

Os padrões de design foram originalmente categorizados em 3 subclassificações com base no tipo de problema que eles resolvem. Os padrões de criação fornecem a capacidade de criar objetos com base em um critério necessário e de maneira controlada. Os padrões estruturais tratam da organização de diferentes classes e objetos para formar estruturas maiores e fornecer novas funcionalidades. Finalmente, os padrões comportamentais tratam da identificação de padrões comuns de comunicação entre objetos e da percepção desses padrões.

Padrões de criação

Nome	Descrição	Em Padrões de Projeto	Em Código Completo [14]	Outro
fábrica abstrata	Forneça uma interface para criar famílias de objetos relacionados ou dependentes sem especificar suas classes concretas.	Sim	Sim	—
Construtor	Separe a construção de um objeto complexo de sua representação, permitindo que o mesmo processo de construção crie várias representações.	Sim	Não	—
Injeção de dependência	Uma classe aceita os objetos que requer de um injetor em vez de criar os objetos diretamente.	Não	Não	—
Método de fábrica	Defina uma interface para criar um único objeto, mas deixe as subclasses decidirem qual classe instanciar. O Factory Method permite que uma classe adie a instanciação para subclasses.	Sim	Sim	—
Inicialização preguiçosa	Tática de atrasar a criação de um objeto, o cálculo de um valor ou algum outro processo caro até a primeira vez em que for necessário. Este padrão aparece no catálogo GoF como "proxy virtual", uma estratégia de implementação para o padrão Proxy .	Não	Não	PoEAA [15]
Multiton	Certifique-se de que uma classe tenha apenas instâncias nomeadas e forneça um ponto de acesso global a elas.	Não	Não	—
Conjunto de objetos	Evite a aquisição cara e a liberação de recursos reciclando objetos que não estão mais em uso. Pode ser considerado uma generalização dos padrões pool de conexão e pool de threads .	Não	Não	—
Protótipo	Especifique os tipos de objetos a serem criados usando uma instância prototípica e crie novos objetos a partir do 'esqueleto' de um objeto existente, aumentando assim o desempenho e mantendo o mínimo de consumo de memória.	Sim	Não	—
A aquisição de recursos é a inicialização (RAII)	Certifique-se de que os recursos sejam liberados adequadamente, vinculando-os à vida útil de objetos adequados.	Não	Não	—
solteiro	Certifique-se de que uma classe tenha apenas uma instância e forneça um ponto de acesso global a ela.	Sim	Sim	—

Padrões estruturais

Nome	Descrição	Em Padrões de Projeto	Em Código Completo [14]	Outro
Adaptador , Wrapper ou Tradutor	Converta a interface de uma classe em outra interface que os clientes esperam. Um adaptador permite que as classes trabalhem juntas, o que não poderia acontecer devido a interfaces incompatíveis. O equivalente do padrão de integração empresarial é o tradutor.	Sim	Sim	—
Ponte	Desacople uma abstração de sua implementação, permitindo que os dois variem independentemente.	Sim	Sim	—
Composto	Componha objetos em estruturas de árvore para representar hierarquias parte-todo. O Composite permite que os clientes tratem objetos individuais e composições de objetos uniformemente.	Sim	Sim	—
Decorador	Anexar responsabilidades adicionais a um objeto mantendo dinamicamente a mesma interface. Os decoradores fornecem uma alternativa flexível à subclasse para estender a funcionalidade.	Sim	Sim	—
Objeto de extensão	Adicionar funcionalidade a uma hierarquia sem alterar a hierarquia.	Não	Não	Desenvolvimento Ágil de Software, Princípios, Padrões e Práticas [16]
Fachada	Forneça uma interface unificada para um conjunto de interfaces em um subsistema. Facade define uma interface de nível superior que torna o subsistema mais fácil de usar.	Sim	Sim	—
Peso Mosca	Use o compartilhamento para suportar um grande número de objetos semelhantes de forma eficiente.	Sim	Não	—
Controlador frontal	O padrão está relacionado ao design de aplicativos da Web. Ele fornece um ponto de entrada centralizado para lidar com solicitações.	Não	Não	Padrões J2EE [17] PoEAA [18]
Marcador	Interface vazia para associar metadados a uma classe.	Não	Não	Java eficaz [19]
Módulo	Agrupe vários elementos relacionados, como classes, singletons, métodos, usados ​​globalmente, em uma única entidade conceitual.	Não	Não	—
Proxy	Forneça um substituto ou espaço reservado para outro objeto para controlar o acesso a ele.	Sim	Não	—
Gêmeo [20]	Twin permite a modelagem de herança múltipla em linguagens de programação que não suportam esse recurso.	Não	Não	—

Padrões de comportamento

Nome	Descrição	Em Padrões de Projeto	Em Código Completo [14]	Outro
Quadro-negro	Padrão de inteligência artificial para combinar fontes de dados diferentes (consulte sistema de quadro-negro )	Não	Não	—
Cadeia de responsabilidade	Evite acoplar o remetente de uma solicitação ao seu destinatário, dando a mais de um objeto a chance de lidar com a solicitação. Encadeie os objetos receptores e passe a solicitação ao longo da cadeia até que um objeto a trate.	Sim	Não	—
Comando	Encapsule uma solicitação como um objeto, permitindo assim a parametrização de clientes com diferentes solicitações e o enfileiramento ou registro de solicitações. Ele também permite o suporte de operações reversíveis.	Sim	Não	—
Intérprete	Dado um idioma, defina uma representação para sua gramática junto com um intérprete que usa a representação para interpretar sentenças no idioma.	Sim	Não	—
Iterador	Forneça uma maneira de acessar os elementos de um objeto agregado sequencialmente sem expor sua representação subjacente.	Sim	Sim	—
Mediador	Defina um objeto que encapsula como um conjunto de objetos interage. O mediador promove acoplamento fraco , impedindo que os objetos se refiram explicitamente, e permite que sua interação varie de forma independente.	Sim	Não	—
Lembrança	Sem violar o encapsulamento, capture e externalize o estado interno de um objeto, permitindo que o objeto seja restaurado a esse estado posteriormente.	Sim	Não	—
objeto nulo	Evite referências nulas fornecendo um objeto padrão.	Não	Não	—
Observer ou Publicar/assinar	Defina uma dependência um-para-muitos entre objetos onde uma mudança de estado em um objeto resulta em todos os seus dependentes sendo notificados e atualizados automaticamente.	Sim	Sim	—
Servo	Defina a funcionalidade comum para um grupo de classes. O padrão de servo também é frequentemente chamado de classe auxiliar ou implementação de classe utilitária para um determinado conjunto de classes. As classes auxiliares geralmente não têm objetos, portanto, elas têm todos os métodos estáticos que agem sobre diferentes tipos de objetos de classe.	Não	Não	—
Especificação	Lógica de negócios recombinável de maneira booleana .	Não	Não	—
Estado	Permite que um objeto altere seu comportamento quando seu estado interno muda. O objeto parecerá mudar de classe.	Sim	Não	—
Estratégia	Definir uma família de algoritmos, encapsular cada um e torná-los intercambiáveis. A estratégia permite que o algoritmo varie independentemente dos clientes que o utilizam.	Sim	Sim	—
Método de modelo	Defina o esqueleto de um algoritmo em uma operação, adiando algumas etapas para subclasses. O método Template permite que as subclasses redefinam certas etapas de um algoritmo sem alterar a estrutura do algoritmo.	Sim	Sim	—
Visitante	Representa uma operação a ser executada em instâncias de um conjunto de classes. Visitor permite definir uma nova operação sem alterar as classes dos elementos sobre os quais opera.	Sim	Não	—
Interface Fluente	Projete uma API para ser encadeada por métodos de modo que seja lida como uma DSL. Cada chamada de método retorna um contexto por meio do qual as próximas chamadas de método lógico são disponibilizadas.	Não	Não	—

Padrões de simultaneidade

Nome	Descrição	Em POSA2 [21]	Outro
Objeto ativo	Separa a execução do método da invocação do método que reside em seu próprio thread de controle. O objetivo é introduzir a simultaneidade, usando invocação de método assíncrono e um agendador para lidar com solicitações.	Sim	—
hesitação	Somente execute uma ação em um objeto quando o objeto estiver em um estado específico.	Não	—
Propriedades de ligação	Combinar vários observadores para forçar as propriedades em diferentes objetos a serem sincronizadas ou coordenadas de alguma forma. [22]	Não	—
Kernel de computação	O mesmo cálculo muitas vezes em paralelo, diferindo por parâmetros inteiros usados ​​com matemática de ponteiro sem ramificação em matrizes compartilhadas, como multiplicação de matriz otimizada para GPU ou rede neural convolucional .	Não	—
Bloqueio duplamente verificado	Reduza a sobrecarga de adquirir um bloqueio testando primeiro o critério de bloqueio (a 'dica de bloqueio') de maneira insegura; somente se isso for bem-sucedido, a lógica de bloqueio real continuará. Pode ser inseguro quando implementado em algumas combinações de linguagem/hardware. Portanto, às vezes pode ser considerado um antipadrão .	Sim	—
Assíncrono baseado em evento	Aborda problemas com o padrão assíncrono que ocorrem em programas multithread. [23]	Não	—
Suspensão vigiada	Gerencia as operações que exigem a aquisição de um bloqueio e a satisfação de uma pré-condição antes que a operação possa ser executada.	Não	—
Juntar	Join-pattern fornece uma maneira de escrever programas simultâneos, paralelos e distribuídos por passagem de mensagem. Comparado ao uso de threads e bloqueios, esse é um modelo de programação de alto nível.	Não	—
Trancar	Um thread coloca um "bloqueio" em um recurso, impedindo que outros threads o acessem ou modifiquem. [24]	Não	PoEAA [15]
Padrão de design de mensagens (MDP)	Permite o intercâmbio de informações (ou seja, mensagens) entre componentes e aplicativos.	Não	—
Monitorar objeto	Um objeto cujos métodos estão sujeitos a exclusão mútua , evitando assim que vários objetos tentem erroneamente usá-lo ao mesmo tempo.	Sim	—
reator	Um objeto reator fornece uma interface assíncrona para recursos que devem ser tratados de forma síncrona.	Sim	—
Bloqueio de leitura e gravação	Permite acesso simultâneo de leitura a um objeto, mas requer acesso exclusivo para operações de gravação. Um semáforo subjacente pode ser usado para gravação e um mecanismo Copy-on-write pode ou não ser usado.	Não	—
Agendador	Controle explicitamente quando os threads podem executar código de thread único.	Não	—
Grupo de discussão	Vários threads são criados para executar várias tarefas, que geralmente são organizadas em uma fila. Normalmente, há muito mais tarefas do que threads. Pode ser considerado um caso especial do padrão pool de objetos .	Não	—
Armazenamento específico do encadeamento	Memória estática ou "global" local para um thread.	Sim	—
Simultaneidade segura com propriedade exclusiva	Evita a necessidade de mecanismos simultâneos de tempo de execução, porque a propriedade exclusiva pode ser comprovada. Esta é uma capacidade notável da linguagem Rust, mas a verificação em tempo de compilação não é o único meio, um programador frequentemente projetará manualmente tais padrões no código - omitindo o uso do mecanismo de bloqueio porque o programador avalia que uma determinada variável nunca vai para serem acessados ​​simultaneamente.	Não	—
Operação atômica da CPU	x86 e outras arquiteturas de CPU suportam uma variedade de instruções atômicas que garantem a segurança da memória para modificar e acessar valores primitivos (inteiros). Por exemplo, dois threads podem incrementar um contador com segurança. Esses recursos também podem ser usados ​​para implementar os mecanismos para outros padrões de simultaneidade como acima. A linguagem C# usa a classe Interlocked para esses recursos.	Não	—

Documentação

A documentação de um padrão de projeto descreve o contexto no qual o padrão é usado, as forças dentro do contexto que o padrão procura resolver e a solução sugerida. ^[25] Não existe um formato padrão único para documentar padrões de projeto. Em vez disso, uma variedade de formatos diferentes foi usada por diferentes autores de padrões. No entanto, de acordo com Martin Fowler , certas formas de padrões tornaram-se mais conhecidas do que outras e, consequentemente, tornaram-se pontos de partida comuns para novos esforços de escrita de padrões. ^[26] Um exemplo de formato de documentação comumente usado é o usado por Erich Gamma , Richard Helm , Ralph Johnson e John Vlissidesem seu livro Design Patterns . Ele contém as seguintes seções:

• Nome e classificação do padrão: Um nome descritivo e exclusivo que ajuda na identificação e referência ao padrão.
• Intenção: Uma descrição do objetivo por trás do padrão e a razão para usá-lo.
• Também conhecido como: Outros nomes para o padrão.
• Motivação (Forças): Um cenário que consiste em um problema e um contexto no qual esse padrão pode ser usado.
• Aplicabilidade: Situações em que este padrão é utilizável; o contexto para o padrão.
• Estrutura: Uma representação gráfica do padrão. Diagramas de classe e diagramas de interação podem ser usados ​​para essa finalidade.
• Participantes: Uma listagem das classes e objetos usados ​​no padrão e suas funções no projeto.
• Colaboração: Uma descrição de como classes e objetos usados ​​no padrão interagem uns com os outros.
• Consequências: Uma descrição dos resultados, efeitos colaterais e trade-offs causados ​​pelo uso do padrão.
• Implementação: Uma descrição de uma implementação do padrão; a parte solução do padrão.
• Código de Amostra: Uma ilustração de como o padrão pode ser usado em uma linguagem de programação.
• Usos conhecidos: Exemplos de usos reais do padrão.
• Padrões Relacionados: Outros padrões que possuem alguma relação com o padrão; discussão das diferenças entre o padrão e padrões semelhantes.

Crítica

Foi observado que os padrões de projeto podem ser apenas um sinal de que alguns recursos estão faltando em uma determinada linguagem de programação ( Java ou C++ , por exemplo). Peter Norvig demonstra que 16 dos 23 padrões no livro Design Patterns (que é focado principalmente em C++) são simplificados ou eliminados (via suporte direto à linguagem) em Lisp ou Dylan . ^[27] Observações relacionadas foram feitas por Hannemann e Kiczales que implementaram vários dos 23 padrões de projeto usando uma linguagem de programação orientada a aspectos(AspectJ) e mostrou que as dependências em nível de código foram removidas das implementações de 17 dos 23 padrões de projeto e que a programação orientada a aspectos poderia simplificar as implementações de padrões de projeto. ^[28] Veja também o ensaio de Paul Graham "Revenge of the Nerds". ^[29]

O uso inadequado de padrões pode aumentar desnecessariamente a complexidade. ^[30]

Veja também

Referências

Leitura adicional