Entonces, "¿Están faltando los patrones de diseño de las características del lenguaje"? [cerrado]

Vi, aquí en Programadores, la respuesta a esta pregunta: ¿cómo cambia el pensamiento sobre patrones de diseño y prácticas de OOP en lenguajes dinámicos y de tipo débil? Allí encontré un enlace a un artículo con un título abierto: Son patrones de diseño que faltan características del lenguaje . Pero cuando encontré fragmentos que me parecieron muy pegadizos y que probablemente se pueden verificar con la experiencia, hay un incentivo para eso, como:

PaulGraham dijo que "Peter Norvig descubrió que 16 de los 23 patrones en Design Patterns eran 'invisibles o más simples' en Lisp".

u otra oración que confirma lo que vi recientemente con personas que intentan simular clases en JavaScript:

Por supuesto, nadie habla nunca del patrón de "función", del patrón de "clase", ni de muchas otras cosas que damos por sentado porque la mayoría de los idiomas los proporcionan como características integradas. OTOH, ¿programadores en un lenguaje puramente prototipo orientado? bien podría resultarle conveniente simular clases con prototipos ...

También estoy teniendo en cuenta que los patrones de diseño son una herramienta de comunicación . Porque incluso con mi experiencia limitada participando en la creación de aplicaciones, puedo ver como un antipatrón ( ineficaz y / o contraproducente ), por ejemplo, lo que obliga a un pequeño equipo de PHP a aprender patrones de GoF para aplicaciones de intranet pequeñas y medianas. Soy consciente de que la escala, el alcance y el propósito pueden determinar qué es efectivo y / o productivo, pero aún así no pude encontrar una descripción técnica al respecto.

Vi pequeñas aplicaciones comerciales que combinaban funcionalmente con OOP y aún se podían mantener, y no sé si muchas necesitarían, por ejemplo, en Python para escribir un singleton, pero para mí un módulo simple hace lo mismo.

Entonces, ¿hay estudios, artículos exhaustivos u otra forma de exposición que tenga en cuenta los patrones de diseño frente a soluciones alternativas frente a formas más sencillas de hacerlo o reemplazos por características del lenguaje?

programming-languages design-patterns

— Eduard Florinescu
fuente

Sería un error aceptar todo lo que Paul Graham dice sobre el tema de los lenguajes de programación como "objetivo y objetivo".

— Mason Wheeler

No tiendo a estar en desacuerdo con Paul Graham, pero @MasonWheeler tiene razón, los evangelistas son excelentes por muchas razones, pero no por su objetividad.

— Jimmy Hoffa

@JimmyHoffa: No se trata de "evangelistas" en general. Estoy en desacuerdo con la larga historia de Graham de publicar material ridículo que frecuentemente se contradice a sí mismo o a sus fuentes y trata de torcer todo para que parezca coherente. No importa de qué se trate, esa es una forma horrible de hacerlo, y para mí es un poco espantoso que la gente realmente lo escuche.

— Mason Wheeler

Sería bueno ver algunos estudios, pero si alguna vez usó lenguajes funcionales modernos, ya sabe cuán obsoletos son los patrones de diseño GOF, y no hay necesidad de números para demostrarlo más . (Sin embargo, fueron importantes en 1990, sin duda).

— c69

@DanielB, cada paradigma específico fallará, porque la realidad es mucho más compleja de lo que podría ser cualquier paradigma. Por lo tanto, cada problema merece su propio modelo y paradigma de dominio específico.

— SK-logic

No conozco ninguna discusión o estudio en profundidad que tenga en cuenta todas esas cosas.

Dicho esto, todo el argumento de "los patrones de diseño son solo parches de características faltantes en los lenguajes OO" es un poco delgado, en mi opinión. Sí, algunos patrones de diseño son exactamente eso, llenan un vacío común que ni siquiera existe en otro lenguaje X. Estos son típicamente sus patrones de diseño más simples y de bajo nivel, como algunos / muchos de los originales en el libro GoF.

Pero los patrones de diseño van mucho más allá de esos simples, y llamarlos características de lenguaje faltantes extiende la imaginación. Eche un vistazo al catálogo de patrones de aplicaciones empresariales de Fowler y piense en cómo sería si todos fueran parte de la definición central de un lenguaje. Supongo que terminarías con un lenguaje específico de dominio ( DSL ) para aplicaciones empresariales (y uno muy complejo, por cierto).

Así que esto es realmente, los patrones de diseño son una forma de encontrar soluciones reutilizables para problemas particulares (que a menudo se aplican en un lenguaje genérico de uso múltiple). Aquí es donde también interviene la comunicación. Si me dice "usamos registros activos", ya sé bastante sobre su aplicación, sin perder minutos discutiendo cuáles son los diversos enfoques. Entonces, sí, los patrones de diseño hacen agujeros en la especificación del lenguaje. ¿Eso es todo lo que hacen? No, no por asomo.

Editar:

En cierto modo, lo que estoy diciendo es que los patrones permiten a los practicantes de OO pensar en un nivel superior y casi construir un tipo de DSL para su entorno, mientras se mantienen dentro de la sintaxis de su idioma. Y sí, he visto lo que sucede cuando los aplicas en todas partes (ver: AbstractSingletonProxyFactoryBean , sí, existe), o creo que son una especie de bala de plata. El punto es que si bien toman mucho tiempo para sentirse realmente cómodos, se supone que en realidad reducen la complejidad al hacer que las cosas sean predecibles / comprensibles a un alto nivel. Esto es muy diferente a ser un kit de parches para las fallas de su idioma.

Edición 2: se agregó el contraejemplo AbstractSingletonProxyFactoryBean para burlarse de los patrones. Para ser completamente justos, cuando se ve desde una luz AOP, incluso este contraejemplo es defendible.

— Daniel B
fuente

(+1) y aceptar porque redujo mi búsqueda en DSL y patrones de aplicación. Muy reflexivo, y ¿podría expandir o vincular para el lector tal vez entre paréntesis al menos una de las siglas DSL? Supongo que significa lenguaje específico de dominio.

— Eduard Florinescu

@EduardFlorinescu gracias, he actualizado con enlaces para DSL.

— Daniel B

También encontré este artículo que confirma parte de su respuesta en este caso con Groovy ibm.com/developerworks/java/library/j-eaed7/index.html

— Eduard Florinescu

@EduardFlorinescu es muy interesante, aunque no solo me refería específicamente al patrón del intérprete; más bien, quise decir que muchos patrones pueden ser bastante específicos del dominio y volverse casi idiomáticos para los desarrolladores en ese dominio. En ese sentido, se convierten en una especie de DSL, y no requieren mucho esfuerzo para comprender y usar. Por ejemplo, cuando leo un patrón de comando (un ejemplo no específico del dominio), sé qué código repetitivo puedo ignorar con seguridad, y no requiere mucho esfuerzo. Pero gracias por el interesante enlace, no obstante.

— Daniel B