¿Patrones de diseño sin OOP? [cerrado]

Eche un vistazo a la serie de patrones de diseño del kernel de Linux. Los artículos están relacionados con un lenguaje no orientado a objetos (C) y creo que están bien escritos:

• Patrones de diseño del kernel de Linux - Parte 1
• Patrones de diseño del kernel de Linux - Parte 2
• Patrones de diseño del kernel de Linux - Parte 3
• Ghosts of Unix Past: una búsqueda histórica de patrones de diseño
• Fantasmas del pasado de Unix, parte 2: Diseños combinados
• Fantasmas del pasado de Unix, parte 3: diseños que no se pueden arreglar
• Fantasmas del pasado de Unix, parte 4: diseños de alto mantenimiento

En realidad, es una paradoja: uno de los patrones más populares que no son OO es ... "Clase".

Debido a que OO se inventó en lenguajes que no son OO, los desarrolladores tuvieron que simularlo (y lo están haciendo incluso ahora), por lo que nació el patrón. LISP y C son ejemplos de esto.

Pero sigue mi consejo: No cometas errores comunes, no uses patrones solo porque es genial , necesitas razones serias para justificar el uso de patrones (al menos OO).

Tomar patrón de Comando, por ejemplo, aunque es bueno & desacopla al que llama del receptor, no debe usarse a menos que realmente lo necesite, porque las operaciones deben expresarse usando verbos, lo que significa métodos. Y al usar comandos en todo el lugar, terminaría con un montón de OO-lambdas completamente descentralizados - > Lo mismo sería cierto para muchas estrategias.

"Patrón de diseño" es en realidad un eufemismo para "solución". Los patrones de diseño se inventaron para solucionar fallas y defectos en los idiomas OO . Por ejemplo, tome el patrón de iterador que finalmente llevó a la introducción de las colecciones en Java. Groovy se deshizo de muchos más patrones convirtiéndolos en características de lenguaje: ya no necesitas el patrón decorador porque puedes agregar métodos a las clases existentes en Groovy.

Esto significa que puedes encontrar patrones de diseño en todas partes. De hecho, todas las "mejores prácticas" pueden considerarse una forma simple de un patrón de diseño.

Menciones de LtU que Jeremy Gibbons está escribiendo un libro sobre patrones en programación funcional. Consulte los Patrones en el blog de Programación Funcional del Sr. Gibbon para ver algunos ejemplos. Tenga en cuenta que recomienda leer sus publicaciones de más antiguo a más reciente.

Su artículo Patrones de diseño como programas de tipo de datos genéricos de orden superior (pdf) modela funcionalmente los patrones de Gang of Four: Compuesto, Iterador, Visitador y Generador. Describe los patrones de programación con ecuaciones recursivas en Origami Programming (se pliega y despliega).

Hay patrones de diseño SQL .

Y también existen algunos patrones de diseño funcional: consulte aquí para obtener información sobre scala.

En lugar de nombrar patrones de diseño que no sean oo, me gustaría darles algunos ejemplos de libros que tienen muchos patrones de diseño (en ellos algunos patrones aún serán específicos de OO):

• Mire el POSA Books para ejemplos en arquitectura de software
  • computación distribuida
  • Patrones para objetos concurrentes y en red
  • Patrones para la gestión de recursos
• Fowlers patrones de arquitectura empresarial con catálogo en línea
• xUnit Test patterns con sitio web
• Y, por supuesto, donde se originaron los patrones: Christopher Alexander forma atemporal de construir

Espero que esto ayude

En la programación funcional (especialmente Haskell), hay muchos patrones y modismos que no se relacionan muy bien con la POO. Phantom types son un ejemplo conocido, y puedes encontrar muchas más en haskell wiki page in Idioms .

Programación modular es bastante popular para bibliotecas numéricas y aplicaciones pesadas en matemáticas (el software numérico es muy difícil de modelar usando el Patrones orientados a objetos, principalmente porque hay muy poco que se puede encapsular).

Un buen ejemplo de patrones sin OOP es mi catálogo de patrones favorito absoluto: Patrones organizativos de desarrollo de software ágil, por James O. Coplien . Este libro no trata sobre patrones de software, trata sobre personas, un catálogo para crear equipos exitosos. ¡Todos los gerentes deberían leer este libro!

Me gusta pensar en estructuras de datos como colas, listas vinculadas, árboles, gráficos, etc. como patrones. Definen ciertos patrones para almacenar datos y procesarlos. Pueden parecer primitivos en comparación con los patrones de gama más alta de Gang of Four, pero son patrones a pesar de todo. Quiero decir, ¿qué pasaría si alguien implementara una pila como FIFO en lugar de LIFO y viceversa para una cola y los nombrara de otra manera?