Patrón de diseño como característica de idioma (faltante)

Algunas veces las personas se refieren a patrones de diseño como características faltantes del lenguaje de programación. Para evitar el debate sobre qué es un patrón de diseño, digamos que solo consideramos los patrones originales de GoF. Por ejemplo, el patrón singleton desaparece en Scala, que admite objetos singleton utilizando la palabra clave object.Patrón de diseño como característica de idioma (faltante)

Hay pocos recursos alrededor de esto, notablemente Are Design Patterns Missing Language Features de la wiki C2, o Are design patterns really language weaknesses? de SO. Pero no pude encontrar una cobertura no obstinada, objetiva e integral de esta pregunta.

Idealmente, quisiera una matriz con los patrones de diseño GoF (fila) y algunos lenguajes de programación convencionales (columnas), donde cada celda se referiría a una discusión sobre el patrón en el lenguaje de programación específico.

Para evitar el debate sobre lo que PL debe tener en cuenta, también podemos solucionarlo y elegir: Java (como representante OO estáticamente tipado), Smalltalk (como un representante tipado dinámicamente), Haskell (como representante funcional), Scala (como un representante funcional oo/híbrido), Lisp (como un representante de meta-programación), JavaScript (como un representante basado en prototipos). Y deje otros PL para notas secundarias o comentarios. Sé que podemos discutir sobre esta elección, pero eso ya sería realmente interesante de tener para estos idiomas.

Esto de todos modos siempre será una pregunta abierta, pero me siento como preguntado como está, esto está lo suficientemente enfocado como para tener una mejor respuesta.

¿Quizás esta matriz ya existe en alguna parte? ¿O alguien tiene suficiente conocimiento para elaborarlo? ¿O alguien es lo suficientemente entusiasta como para comenzar y convertirlo en una respuesta wiki para que otros puedan continuar?

Fuente

2010-10-27 ewernli

En lugar de hacer una pregunta subjetiva abierta sobre SO, ¿por qué no simplemente escribes una publicación de blog y la desarrollas a medida que encuentras nuevas implementaciones de un patrón? – slugster

No hay una mejor respuesta posible para esto. Yo votaría por wiki de la comunidad. –

@slugster Mi idea es, de hecho, escribir una publicación de blog (o una de mis amigas lo hará), y la pregunta es sobre la recopilación de referencias a las mejores discusiones sobre el patrón específico w.r.t a un idioma determinado. Entonces puedo compilar eso en una entrada de blog. Mientras tanto, probablemente también responderé mi propia pregunta y esbozaré un borrador de la matriz. – ewernli

Los patrones en Patrones de diseño son un subconjunto del conjunto cada vez mayor de patrones que las personas usan cuando programan en diferentes idiomas. Los autores tienen muy claro que esos patrones solo se aplican a los lenguajes de programación orientada a objetos, por lo que muchos de ellos no tendrán sentido fuera de ese contexto.

Al mismo tiempo, hay muchos patrones en otros idiomas que no son necesarios en un lenguaje OOP. Considere que los objetos en sí mismos son un patrón cuando se implementan en C o Scheme. En el ensamblaje, una pila de llamadas es un patrón.

Fuente

2010-10-27 01:45:45 munificent

+1, escribí el código OO C (y el código C de la máquina de estado, que puede ser bastante similar). Diría que en cualquier dispositivo con más de 100K de espacio de código, una pila de llamadas escrita en ensamble es un grito de ayuda más que un patrón. – detly

Derecha, algunos patrones no se aplican en otro contexto. También me parece bien omitir patrones que no son relevantes en absoluto, o mencionar cuando un patrón no tiene ningún sentido en otro idioma/paradigma. Pero creo que los siguientes patrones merecerían una discusión fuera del contexto OO: Adaptador, Decorador, Proxy, Comando, Intérprete, Observador, Estado, Estrategia, Visitante. Y sí, hay muchos patrones y lenguaje, así que de alguna manera debo restringir el alcance de la pregunta. – ewernli

Personalmente, después de pasar algunos años haciendo OOP, encontré que el problema con los patrones de diseño es que resaltan los problemas con OOP y lo difícil que es ver patrones en los datos que están tan relacionados con el dominio en que está siendo modelado. A veces es muy difícil ver la madera de los árboles. Algunos artefactos en OOP simplemente están ahí para curar los problemas que existen al pensar en ese paradigma particular o al rodear el estado encapsulado y el acceso.

Creo que los patrones de diseño son geniales y los uso, sin embargo se han considerado como la solución a un problema que puede existir en la incapacidad de OOP para ser objetivo sobre estructuras de datos y funciones, por lo que la fórmula probada puede ser aplicado. Un ejemplo simple sería el objeto Singleton. Esto simplemente desaparece cuando se usan lenguajes funcionales y no es un problema.

Como dijo un caballero en SO cuando pregunté sobre UML y si podría usarse para modelar Lenguajes Funcionales, dijo que el lenguaje de modelado de los lenguajes de programación funcional es matemática. Creo que esta es la clave para entender por qué los patrones no son relevantes para los lenguajes de programación funcional, ya que la teoría detrás de ellos está impregnada de las estructuras de las matemáticas.

No puedo ayudarte con una hoja de cuna, pero puedo estar bastante seguro de que los patrones de GOF no se aplican a lenguajes de programación funcionales, ya que van directamente a los patrones reales de las matemáticas ya que la belleza de los lenguajes funcionales que mapean directamente (en la mayoría de los casos) a muchos años resolviendo problemas matemáticos. Tal vez una afirmación descarada es que los patrones de diseño de los lenguajes funcionales son teoremas matemáticos con una relación uno a uno donde OO tiene una forma de abstracciones artificiales que a veces se pone en el camino.

Creo que hay algunos principios de diseño que se cruzan con todos los idiomas, como MVC, la arquitectura de varios niveles, la ampliación y la ampliación. Pero estos los consideraría no como patrones de diseño, sino como buenas prácticas de diseño de software.

Fuente

2010-10-27 02:54:10 WeNeedAnswers

Lo que en realidad dice es que algunos patrones desaparecen cuando se usa otro idioma y en realidad es lo que me gustaría investigar. Sin embargo, tal vez debería comenzar primero extrayendo el problema que resuelve el patrón GoF, y luego ver cómo se resuelve el problema en otro idioma. P.ej. el problema de la singularidad de la estructura de objetos o datos se resuelve con el singleton en OO y desaparece en un lenguaje funcional estricto. ¿O hay algún tipo de relación conceptual entre una clase de tipo Haskell y el patrón compuesto? Claro, comparo un poco las manzanas y las naranjas, pero eso es lo que es interesante. – ewernli

O el hecho de que para interpretar un AST en OO usa el visitante mientras no lo necesita en funcional debido a la sobrecarga (vea el problema de expresión). O el patrón de intérprete que desaparece es la metaprogramación de soporte PL. O el adaptador si tiene algo así como los extractores y los extractores de Scala, etc. – ewernli

Sí, estoy interesado en la comparación también. Los patrones de GOF se relacionan con el Diseño Orientado a Objetos, no creo que lo que representan sea algo nuevo, pero hicieron que los patrones/algoritmos fueran accesibles para todos los días como yo. Con toda ignorancia, simplemente los tomé como pautas, pero después de ver el estilo funcional en profundidad últimamente, estoy empezando a darme cuenta de que hay mucha más profundidad para ellos. El patrón de visitante es un ejemplo OO clásico de lo que básicamente es una función que convierte una forma en otra. – WeNeedAnswers

Patrón de diseño como característica de idioma (faltante)

Respuesta

Cuestiones relacionadas