¿Por qué no se agregan patrones de diseño a las construcciones de idiomas?

Recientemente estaba hablando con un colega que mencionó que su compañía estaba trabajando para agregar el patrón de diseño MVC como una extensión de PHP.

Explicó que escribieron código C para agregar Controllers, Models and Viewsa las construcciones del lenguaje para aumentar el rendimiento.

Ahora sé que MVC es un patrón de diseño arquitectónico que se usa ampliamente en aplicaciones web, pero todavía tengo que encontrar idiomas que tengan una construcción de lenguaje para Controladores, por ejemplo.

En mi humilde opinión, integrar patrones de diseño en un lenguaje puede enfatizar la importancia de un buen diseño OO.

Entonces, ¿por qué no se agregan los patrones de diseño más utilizados (MVC, Factory, Strategy, ... etc.) A las construcciones del lenguaje?

Si la pregunta suena demasiado amplia, puede limitar la pregunta solo a PHP.

Editar:

No estoy implicando que uno deba usar un patrón de diseño al desarrollar un proyecto. En realidad, promuevo la metodología de mantenerlo simple mientras funcione.

Los patrones de diseño se agregan a las construcciones de lenguaje todo el tiempo. ¿Has oído hablar del patrón de diseño de llamadas de subrutina ? ¿No? Yo tampoco. Esto se debe a que las llamadas de subrutina, que eran un patrón de diseño a principios de la década de 1950, se agregaron a los idiomas de manera casi instantánea. Hoy en día, incluso están presentes en los conjuntos de instrucciones de código de máquina de CPU.

¿Qué pasa con el patrón de diseño For Loop ? ¿El patrón de diseño While Loop ? ¿El patrón de diseño del interruptor ? El patrón de diseño de objetos ? El patrón de diseño de clase ? Todos estos se han agregado a algunos idiomas.

Algunos de ellos son. Por ejemplo, los iteradores son características del lenguaje en muchos idiomas y sus bibliotecas estándar (hola, foreach y rendimiento). Observer también está presente con frecuencia en forma de eventos (no en PHP; debe administrar la suscripción de devolución de llamada usted mismo). El comando es la característica principal en WPF.

Muchos de los otros no se beneficiarían realmente de la compatibilidad con el idioma (y harían que el idioma sea más engorroso): ¿cómo simplificaría los Controladores si pudiera diseñar la función de idioma para ellos? Como clases, se benefician de toda la infraestructura ya presente para admitir clases: puede crear instancias, pasarlas y, por ejemplo, probarlas en la unidad como cualquier otro objeto.

El único componente de MVC que IMO podría beneficiarse de algún tipo de soporte de lenguaje es View (con algún motor de plantillas oficial), y en PHP ya es compatible, puede crear y cargar dinámicamente scripts PHP (que a menudo son algún tipo de preprocesamiento utilizado como plantillas).

Lo mismo se aplica al método de fábrica: ¿cómo simplificaría eso si pudiera tener algún tipo de función de idioma que quisiera? Una característica de la que carecen algunos lenguajes (como C ++) es la capacidad de construir objetos a partir de este nombre de tipo, pero la mayoría de los lenguajes de nivel superior pueden hacerlo (y ni siquiera es necesario crear métodos de fábrica útiles). Aparte de eso, todo lo que necesita es poder crear un método que instancia y devuelve un objeto.

De hecho, algunos patrones de diseño se agregan como construcciones de lenguaje, simplemente no se identifican como tales porque la gente comienza a considerarlos como "sintaxis" una vez que están incorporados. El manejo de excepciones en Java es un buen ejemplo: muchas personas codificarían algo similar explícitamente como patrón de diseño si no formaba parte de la sintaxis central.

Pero para centrarse en la pregunta, hay muchas razones por las que no querría agregar demasiados patrones de diseño a un lenguaje:

• No es necesario agregarlos como construcciones de lenguaje: todos los patrones de diseño se pueden implementar de otras maneras
• Complicaría el idioma : esta es una mala idea, ya que hace que el idioma sea más difícil de aprender, hace que los compiladores y las herramientas sean más difíciles de escribir.
• Existen enfoques de implementación alternativos para muchos patrones de diseño. Elegir un enfoque y bendecirlo como parte del lenguaje central probablemente llevaría a las personas a usar ese enfoque sobre los demás (lo que podría ser mucho mejor en algunas circunstancias)
• La excesiva dependencia de los patrones de diseño es probablemente una mala idea en cualquier caso: los diseñadores de idiomas probablemente se den cuenta de que no deberían alentarlos aún más.

Además, si usa un lenguaje suficientemente potente con capacidades de metaprogramación (por ejemplo, un Lisp), se vuelve relativamente sencillo extender el lenguaje usted mismo para implementar cualquier patrón de diseño. No necesita ningún patrón en absoluto en el lenguaje principal si es fácil agregar el suyo propio con una macro de 5 líneas.

¿Por qué no se agregan los patrones de diseño más utilizados (MVC, Factory, Strategy, ... etc.) A las construcciones del lenguaje?

La mayoría de estos patrones pueden implementarse en la mayoría de los lenguajes de programación sin soporte lingüístico específico. Tomemos por ejemplo MVC en Java:

• Puedes codificarlo directamente.
• Puede implementarlo usando un generador de aplicaciones ... y cuidar de muchas otras repeticiones al mismo tiempo.
• Puede implementarlo usando clases de biblioteca "framework".
• Puede implementarlo mediante anotaciones y procesamiento de anotaciones estático o en tiempo de ejecución.

Dadas todas estas opciones, tiene poco valor extender directamente el idioma. Y hay una serie de "inconvenientes":

• Tendería a saturar la sintaxis del lenguaje, (posiblemente) haciendo la vida más difícil para los programadores novatos.
• Tendería a hacer que la especificación del lenguaje sea más grande y más compleja, lo que dificultaría a los implementadores del lenguaje. (Y, por supuesto, cuanto mayor sea la especificación, más probable será que haya errores e inconsistencias).
• Siempre habrá presión para agregar otro patrón ... que genere problemas / inquietudes con la estabilidad del lenguaje.
• Al admitir patrones específicos en el lenguaje, se conectan formas específicas de admitir los patrones, que pueden no adaptarse a algunas aplicaciones.

Son.

Las funciones eran un patrón de diseño en el código ensamblador antes de convertirse en una construcción de lenguaje en C.

Las funciones virtuales eran un patrón de diseño en C antes de convertirse en una construcción de lenguaje en C ++.

Sin embargo, hay una compensación. Si el patrón implica la producción de código repetitivo (incluso un par de palabras clave), eso es una indicación de que sería una característica útil del lenguaje. Pero si el patrón es simple y claro, por ejemplo. C "for (int i = 0; i <10; i ++)", sigue siendo útil para todos escribirlo de la misma manera, pero no es significativamente más largo que "for i = 0 to 10" y tiene la ventaja significativa de que es obvio cómo alterarlo para hacer un bucle ligeramente diferente.

Lea el libro 'gang of four' y quedará claro que:

1. Los patrones de diseño en el libro son en realidad convenciones de Smalltalk bien codificadas en otros lenguajes OO.
2. Como tal, esos patrones no se pueden incluir en el lenguaje OO, sería reimplementar smalltalk dentro de esos idiomas; es mejor usar smalltalk directamente
3. La razón por la cual los patrones de diseño son útiles es porque no enfatizan el papel del lenguaje utilizado actualmente y se enfoca en otros temas además de la sintaxis. Codificar esos patrones dentro del lenguaje perdería esta característica de los patrones de diseño.
4. El verdadero problema en la pregunta anterior es que se pierde el punto de que escribir software no se trata solo de aprender el idioma. Es importante alejarse lo suficiente del idioma que proporciona directamente y centrarse en los requisitos actuales.

Porque los patrones de diseño se implementan perfectamente bien con el código de usuario. Su ejemplo solo sucedió porque es PHP, pero si realmente necesitara rendimiento, simplemente trabajaría en otro idioma o obtendría HipHop o algo así.

Las características del lenguaje son complicadas, tanto para especificar como para implementar, y no es justificable crear una con el único propósito de "Los modismos actuales son X". Apenas guardaría un código de usuario significativo, y para nada.

Eh, pregunta rancia pero no estoy de acuerdo con muchas de las respuestas dependiendo de dónde establezca "Patrones de diseño" en el dial semántico, incluido el aceptado.

En el sentido del libro GoF Design Patterns, diría que depende. MVC, por ejemplo (no es realmente un patrón GoF pero se ajusta a ese molde), es totalmente inapropiado para expresarse como construcciones de lenguaje para consumo masivo (aunque podría tener sentido para un proyecto PHP específico). Como patrón arquitectónico, hay variaciones constantes en el tema y una amplia variedad de interpretaciones perfectamente legítimas sobre él para diferentes circunstancias (aunque muchos se alejan tanto de MVC que probablemente ya no deberían llamarlo MVC). Por ejemplo, en la web, la barrera http lo hace un poco incómodo dependiendo de si está tratando de incluir el lado del cliente (sin duda dolorosamente) en la ecuación y lo que está considerando "la vista" desde un punto de vista más apropiadamente estrictamente perspectiva del lado del servidor.

Iterator, por otro lado, es un concepto muy general que se puede aplicar de una gran variedad de formas a una gran variedad de construcciones.

Donde se debe trazar una línea sobre si algo pertenece en un diseño de lenguaje central, incluso en un lenguaje específico del lado del servidor, IMO, es el punto donde algo cruza la línea para que sea más fácil hacer una cantidad incalculable de cosas más fácilmente en comparación con hacer algo demasiado específico pero ampliamente implementado, como un patrón de arquitectura para usted.