Padrões de design que não são OOP? [fechadas]

70

Eu só ouvi o termo "padrão de design" ser usado para código orientado a objetos, e os padrões GoF incluem apenas padrões de design OOP, mas padrões de design são soluções elegantes para problemas de programação comuns, certo? Não há nada dizendo que eles devem estar limitados ao POO, existe?

Eu gostaria de ver alguns exemplos de padrões de design fora do domínio da programação orientada a objetos. Voc ~ e tem algum? Será que existe mesmo (nenhum livro, como o GoF, deve necessariamente ter sido escrito, deve ser usado apenas; basta)?

Eles podem ser específicos para algumas linguagens de programação, mas padrões gerais (em nível de paradigma) são preferidos, de outros paradigmas além do orientado a objetos.

design-patterns

— Anto
fonte

8

Eu acho que o maior desserviço que os livros populares de padrões de design fizeram foi criar um grande número de pessoas que acreditavam que os padrões se aplicam apenas a linguagens orientadas a objetos. Os padrões criacionais são discutíveis, mas praticamente todos os outros podem e são implementados em nenhuma linguagem orientada a objetos o tempo todo. Estou certo de que esse efeito colateral não era a intenção do autor, mas um efeito colateral.

— Pemdas 12/04

14

Bem, os objetos são um padrão de design em línguas não-OO :)

— back2dos

11

pior ainda, os livros de padrões criaram uma classe inteira de pessoas que acreditam que todo e qualquer problema deve ser resolvido através da aplicação de um padrão específico (geralmente o último que foram ensinados por algum professor da escola que acredita o mesmo).

— Jwenting 31/05

25

Dê uma olhada na série Linux Kernel Design Patterns. Os artigos estão relacionados a uma linguagem não orientada a objetos (C) e acredito que sejam bem escritos:

— sakisk
fonte

Eles estão usando uma abordagem orientada a objetos.

— Kais 28/11

12

Na verdade, é paradoxo - um dos padrões não-OO mais populares é ... "Classe".

Como o OO foi inventado em linguagens não OO, os desenvolvedores tiveram que simular (e estão fazendo isso agora) - então o padrão nasceu. LISP e C são exemplos disso.

Mas siga meu conselho: não cometa erros comuns - não use padrões apenas porque é legal , você precisa de motivos sérios para justificar o uso de padrões (pelo menos os OO).

Tomemos o padrão de comando, por exemplo - embora seja bom e dissocie o chamador do receptor, ele não deve ser usado a menos que você realmente precise disso - porque as operações devem ser expressas usando verbos - o que significa métodos. E usando comandos em todo o lugar, você acabaria com um monte de OO-lambdas completamente descentralizadas -> o mesmo para muitas estratégias.

— Kamil Tomšík
fonte

11

"Padrão de design" é na verdade um eufemismo para "solução alternativa". Os padrões de design foram inventados para solucionar deficiências e falhas nos idiomas OO . Por exemplo, considere o padrão do iterador que eventualmente levou à introdução das coleções em Java. O Groovy se livrou de muitos outros padrões convertendo-os em recursos de idioma: Você não precisa mais do padrão decorador porque pode adicionar métodos às classes existentes no Groovy.

Isso significa que você pode encontrar padrões de design em qualquer lugar. De fato, todas as "melhores práticas" podem ser consideradas uma forma simples de um padrão de design.

— Aaron Digulla
fonte

9

Acordado! De Paul Graham : "Por exemplo, no mundo OO, você ouve bastante sobre" padrões ". [...] Quando vejo padrões em meus programas, considero isso um sinal de problemas. A forma de um programa deve refletir apenas o problema que ele precisa resolver.Qualquer outra regularidade no código é um sinal, pelo menos para mim, de que estou usando abstrações que não são poderosas o suficiente - geralmente estou gerando manualmente as expansões de alguma macro que eu preciso escrever ".

— Andrés F.

7

Não concordo que um padrão de design seja uma solução alternativa. Os dois são opostos. Uma solução alternativa é um patch de curto prazo, montado para contornar um obstáculo específico. Os padrões de design são soluções reutilizáveis a longo prazo. O objetivo do padrão decorador é adicionar funcionalmente 'sem' modificar a classe. Você pode colocar decoradores diferentes em um objeto sem que ele saiba.

— Despertar

A razão pela qual os padrões são considerados uma "solução alternativa" é porque decorar um objeto deve ser um recurso do idioma. Em vez disso, temos que escrever muitas, muitas linhas de código para implementar isso. Como exemplo, o padrão do iterador se tornou parte de muitas linguagens modernas. Para idiomas OO mais antigos, você precisa pular algumas etapas para simulá-los.

— Aaron Digulla

@AaronDigulla Não vejo por que você acha que um padrão como o decorador é uma implementação tão pesada; você está falando sobre algumas linhas de código. Uma classe contém outra classe e encaminha solicitações para ela com algumas funcionalidades adicionais. Ele usa herança e composição de uma maneira que torna a chamada de um objeto decorado equivalente à chamada do próprio objeto. Considero essa transparência uma força. Isso permite que você troque decoradores em tempo de execução. Quando você diz que o groovy não precisa de decorador porque pode adicionar métodos a uma classe, parece que você está perdendo o objetivo.

— Despertar

2

O padrão Iterator não foi substituído por nenhum novo recurso de idioma nos idiomas modernos. Ele vem apenas com uma implementação padrão para coleções comuns. Só porque tem uma implementação padrão, não significa que o padrão não está sendo usado. Se você escrever sua própria coleção, precisará implementá-la.

— Despertar

10

LtU menciona que Jeremy Gibbons está escrevendo um livro sobre padrões em programação funcional. Confira o blog Patterns in Functional Programming do Sr. Gibbon para alguns teasers. Observe que ele recomenda ler suas postagens da mais antiga para a mais nova.

Seu artigo Design Patterns como programas genéricos de tipo de dados de ordem superior (pdf) modela funcionalmente os padrões do Gang of Four: Composite, Iterator, Visitor e Builder. Ele descreve os padrões de programação com equações recursivas na Programação de Origami (dobras e desdobram).

— Março de Corbin
fonte

9

Existem padrões de design SQL .

E alguns padrões de design funcional também existem - veja aqui o scala.

— Oded
fonte

O link scala é quebrado

— corvus_192

7

Em vez de nomear padrões de design que não sejam oo, gostaria de dar alguns exemplos de livros que têm muitos padrões de design (neles, alguns padrões ainda serão específicos de OO):

Veja os livros da POSA para exemplos em arquitetura de software
- Computação distribuída
- Padrões para objetos simultâneos e em rede
- Padrões para Gerenciamento de Recursos
Padrões de arquitetura corporativa com catálogo on-line
Padrões de teste xUnit com site
E, é claro, de onde os padrões se originaram: a maneira atemporal de construção de Christopher Alexander

Espero que isto ajude

— KeesDijk
fonte

Estes são os que eu recomendaria também, além dos padrões de integração corporativa da Hohpe & Woolf .

— TMN

Padrões de Fowler são altamente OO :)

— David Conde

@ David David: A maioria deles é pura OO, todos eles são escritos de maneira OO, mas alguns também se aplicam a não OO: veja "padrões de apresentação na Web", "padrões de estado da sessão", "padrões de distribuição "

— KeesDijk

2

Na programação funcional (especialmente Haskell), existem muitos padrões e expressões que não são muito bem mapeados para o OOP. Os tipos de fantasmas são um exemplo bem conhecido, e você pode encontrar muito mais na página wiki de haskell em Idiomas .

— yatima2975
fonte

1

A programação modular é bastante popular para bibliotecas numéricas e aplicativos pesados em matemática (o software numérico é notoriamente difícil de modelar usando os padrões Orientados a Objetos, principalmente porque há muito pouco que você pode encapsular).

— quant_dev
fonte

Usado em JS e "pure C": en.wikipedia.org/wiki/Module_pattern

— umlcat

1

Um bom exemplo de padrões que não são OOP é o meu catálogo de padrões favoritos absoluto: Padrões Organizacionais de Desenvolvimento Ágil de Software, de James O. Coplien . Este livro não trata de padrões de software, trata-se de pessoas, um catálogo para a criação de equipes de sucesso. Todo gerente deve ler este livro!

— JuanZe
fonte

0

Eu gosto de pensar em estruturas de dados como filas, listas vinculadas, árvores, gráficos etc. como padrões. Eles definem certos padrões para armazenar dados e processá-los. Eles podem parecer primitivos em comparação com os padrões mais sofisticados do Gang of Four, mas ainda assim são padrões. Quero dizer, o que aconteceria se alguém implementasse uma pilha como um FIFO em vez de um LIFO e vice-versa para uma fila e os nomeasse de outra forma?

— DPD
fonte