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

Dê uma olhada na série Padrões de Design do Kernel do Linux. Os artigos estão relacionados com uma linguagem não orientada a objetos (C) e acredito que estejam bem escritos:

• Padrões de design de kernel do Linux - Parte 1
• Padrões de design do kernel Linux - Parte 2
• Padrões de design do kernel Linux - Parte 3
• Fantasmas do passado do Unix: uma busca histórica por padrões de design
• Fantasmas do passado do Unix, parte 2: Desenhos confinados
• Fantasmas do Unix passado, parte 3: Desenhos não-fixáveis
• Fantasmas do Unix passado, parte 4: Projetos de alta manutenção

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

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

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

Tome padrão de comando, por exemplo - embora seja bom & separa o chamador do receptor, 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 todo o lugar que você acabaria com um monte de OO-lambdas completamente descentralizadas - > o mesmo seria verdade para muitas estratégias.

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

Isso significa que você pode encontrar padrões de design em todos os lugares. Na verdade, qualquer "melhor prática" pode ser considerada uma forma simples de um padrão de design.

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

Seu trabalho Padrões de design como programas genéricos de tipo hierárquico de ordem superior (pdf) funcionalmente modela os padrões da Gang of Four: Composite, Iterator, Visitor e Builder. Ele descreve os padrões de programação com equações recursivas em Programação de Origami (dobra e desdobra).

Existem padrões de design do SQL .

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

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

• Veja os Livros 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 Fowlers de arquitetura corporativa com caminho on-line
• Padrões de teste xUnit com site
• E, claro, onde os padrões se originaram: maneira intemporal de construir de Christopher Alexander

Espero que isso ajude

Na programação funcional (especialmente Haskell), existem muitos padrões e expressões idiomáticas que não mapeiam muito bem a OOP. Os tipos fantasmas são um exemplo bem conhecido, e você pode encontrar muito mais sobre o haskell página wiki em idiomas .

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

Um bom exemplo de padrões não-OOP é o meu catálogo de padrões absoluto favorito: Padrões Organizacionais do Desenvolvimento Ágil de Software, por James O. Coplien . Este livro não é sobre padrões de software, é sobre pessoas, um catálogo para criar equipes de sucesso. Todo gerente deve ler este livro!

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 padrões mais altos de Gang of Four, mas eles são padrões, no entanto. Quero dizer, o que aconteceria se alguém implementasse uma pilha como FIFO em vez de LIFO e vice-versa para uma fila e desse o nome de outra forma?