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

70

Solo he escuchado el término "patrón de diseño" que se usa para el código orientado a objetos, y los patrones de GoF incluyen solo patrones de diseño de OOP, pero los patrones de diseño son soluciones elegantes para problemas de programación comunes, ¿verdad? No hay nada allí que diga que deben limitarse a OOP, ¿verdad?

Me gustaría ver algunos ejemplos de patrones de diseño fuera del ámbito de la programación orientada a objetos. ¿Usted tiene alguna? ¿Existe esto (ningún libro, como el libro GoF, necesariamente debe haber sido escrito, solo debe usarse, eso es suficiente)?

Pueden ser específicos de algunos lenguajes de programación, pero se prefieren los patrones generales (a nivel de paradigma) de otros paradigmas que el orientado a objetos.

design-patterns 
— Anto
fuente
8
Creo que el mayor perjuicio que hicieron los libros de patrones de diseño populares fue crear una gran cantidad de personas que creían que los patrones solo se aplican a los lenguajes orientados a objetos. Los patrones de creación son discutibles, pero casi todos los demás pueden y se implementan en lenguajes orientados a objetos todo el tiempo. Estoy seguro de que este efecto secundario no fue la intención del autor, sino un efecto secundario.
— Pemdas
14
Bueno, los objetos son un patrón de diseño en lenguajes que no son OO :)
— back2dos
1
peor aún, los libros de patrones crearon una clase completa de personas que creen que todos y cada uno de los problemas deben resolverse aplicando un patrón específico (generalmente el último que les enseñó un maestro de escuela que él mismo cree lo mismo).
— Jwenting

Respuestas:

25

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

— sakisk
fuente
Sin embargo, están utilizando un enfoque orientado a objetos.
— Kais
12

En realidad, es una paradoja: uno de los patrones más populares de OO no 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 tome mi consejo: no cometa un error común: no use patrones solo porque es genial , necesita razones serias para justificar el uso del patrón (al menos OO).

Tome el patrón de Comando, por ejemplo, aunque es agradable y desacopla a la persona 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 usando comandos en todo el lugar, terminaría con un montón de OO-lambdas completamente descentralizadas;> lo mismo sería cierto para muchas Estrategias.

— Kamil Tomšík
fuente
11

El "patrón de diseño" es en realidad un eufemismo para la "solución". Los patrones de diseño se inventaron para evitar fallas y defectos en los idiomas OO . Por ejemplo, tome el patrón iterador que finalmente condujo a la introducción de las colecciones en Java. Groovy se deshizo de muchos más patrones al convertirlos en funciones de lenguaje: ya no necesita el patrón decorador porque puede agregar métodos a las clases existentes en Groovy.

Esto significa que puede encontrar patrones de diseño en todas partes. De hecho, cada "mejor práctica" puede considerarse una forma simple de un patrón de diseño.

— Aaron Digulla
fuente
9
¡Convenido! De Paul Graham : "Por ejemplo, en el mundo OO se escucha mucho sobre" patrones ". [...] Cuando veo patrones en mis programas, lo considero un signo de problemas. La forma de un programa debe reflejar solo el problema que necesita resolver. Cualquier otra regularidad en el código es una señal, al menos para mí, de que estoy usando abstracciones que no son lo suficientemente potentes, a menudo que estoy generando a mano las expansiones de alguna macro que necesito escribir ".
— Andres F.
77
No estoy de acuerdo con que un patrón de diseño sea una solución alternativa. Los dos son opuestos. Una solución alternativa es un parche a corto plazo creado para evitar un obstáculo específico. Los patrones de diseño son soluciones reutilizables a largo plazo. El propósito del patrón decorador es agregar funcionalmente 'sin' modificar la clase. Puede colocar diferentes decoradores en un objeto sin que el objeto lo sepa.
— Despertar el
La razón por la cual los patrones se consideran una "solución" es porque decorar un objeto debería ser una característica del lenguaje. En cambio, tenemos que escribir muchas, muchas líneas de código para implementar esto. Como ejemplo, el patrón iterador se ha convertido en parte de muchos lenguajes modernos. Para los idiomas OO más antiguos, debe saltar un par de aros para simularlos.
— Aaron Digulla
@AaronDigulla No veo por qué piensas que un patrón como el decorador es una implementación tan pesada; estás hablando de unas pocas líneas de código. Una clase contiene otra clase y le envía solicitudes con alguna funcionalidad adicional. Utiliza la herencia y la composición de una manera que hace que llamar a un objeto decorado sea equivalente a llamar al objeto mismo. Considero que esta transparencia es una fortaleza. Esto le permite intercambiar decoradores en tiempo de ejecución. Cuando dices que Groovy no necesita decorador porque puede agregar métodos a una clase, parece que te estás perdiendo el punto.
— Despertar
2
El patrón Iterator no ha sido reemplazado por ninguna nueva función de idioma en los idiomas modernos. Solo viene con una implementación predeterminada para colecciones comunes. El hecho de que tenga una implementación predeterminada no significa que el patrón no se esté utilizando. Si escribe su propia colección, deberá implementarla usted mismo.
— Despertar
10

LtU menciona que Jeremy Gibbons está escribiendo un libro sobre patrones en programación funcional. Echa un vistazo al blog Patrones en programación funcional del Sr. Gibbon para ver algunos avances. Tenga en cuenta que recomienda leer sus publicaciones de la más antigua a la más reciente.

Su documento Design Patterns as Higher-Order Datatype-Generic Programs (pdf) modela funcionalmente los patrones Gang of Four: Composite, Iterator, Visitor y Builder. Describe los patrones de programación con ecuaciones recursivas en Origami Programming (pliegues y despliegues).

— Corbin March
fuente
7

En lugar de nombrar patrones de diseño que no sean ooo, me gustaría darle algunos ejemplos de libros que tienen muchos patrones de diseño (en ellos, algunos patrones seguirán siendo específicos de OO):

Espero que esto ayude

— KeesDijk
fuente
Estos son los que también recomendaría, además de los patrones de integración empresarial de Hohpe & Woolf .
— TMN
Los patrones de Fowler son muy OO :)
— David Conde
@David Conde :) La mayoría de ellos son OO puros, todos están escritos de forma OO, pero algunos de ellos también se aplican a OO no: mira "Patrones de presentación web", "Patrones de estado de sesión", "Patrones de distribución "
— KeesDijk
0

Me gusta pensar en estructuras de datos como colas, listas enlazadas, árboles, gráficos, etc. como patrones. Definen ciertos patrones para almacenar datos y procesarlos. Pueden parecer primitivos en comparación con los patrones más sofisticados de Gang of Four pero, sin embargo, son patrones. 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?

— DPD
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.