design-patterns - ejemplos - patrones de diseño pdf

¿Los patrones de diseño son realmente debilidades en el lenguaje? (11)

¿Deberían los patrones de hoy ser vistos como defectos o características faltantes en Java y C ++ ?

La subrutina fue un patrón de diseño para lenguaje de máquina en los años 50 y 60.
Object-Oriented Class fue un patrón de diseño para C en los años 70.
Los visitantes, las fábricas abstractas, los decoradores y las fachadas son hoy en día patrones de diseño para Java y C ++.
¿Cómo serán los idiomas de mañana? ¿Qué patrones tendrán?

Algunos patrones de diseño canonizados - Adaptador, Fábrica, Comando, Visitante, etc. - son aproximaciones de características que se procesan en otros idiomas. La parte superior de mi cabeza:

Los controladores de eventos en C # son versiones horneadas del patrón del observador. Piensa en cómo tendrías que conectar los eventos en C # si debías rodar tu propio observador cada vez.
El patrón de visitante es una aproximación detallada de multimethods , reenvío de mensajes o una forma realmente débil de coincidencia de patrones .
El patrón de comando envuelve un comportamiento particular para que pueda pasar el objeto entre los métodos, lo que se aproxima más o menos a las funciones de primera clase.
El patrón de estrategia le permite insertar dinámicamente un comportamiento en un objeto, de modo que en cualquier momento puede modificar el objeto intercambiando un comportamiento con otro. En el mundo de la programación funcional, llamamos a esta función composición.
El patrón abstracto de fábrica acepta un argumento y devuelve una fábrica como resultado. En general, puede pensar que las fábricas son básicamente envoltorios alrededor de una función (más específicamente, envoltorios alrededor de un constructor). Entonces, pasas argumentos a una función y obtienes una función como resultado, haciendo que este patrón sea bastante análogo al currying.
El patrón decorador le permite adjuntar o eliminar comportamientos a un objeto en tiempo de ejecución. En JavaScript, puede agregar o eliminar funciones sin implementar explícitamente el patrón de decorador gracias al modelo OO "prototipo".

Entonces, tenemos un montón de patrones de diseño que emulan las características intrínsecas de otros lenguajes. La envidia característica no necesariamente indica una debilidad en el lenguaje; es el código repetitivo que necesita escribir una y otra vez, lo que indica la debilidad del idioma.

Cada cosa que haces tres o más veces en diseños de software forma un patrón.

Cada repetición Cada repetición Cada repetición

Algunos se canonizan con nombres geniales. Estos se convierten en patrones de diseño. Repetición consciente

Algunas son solo "mejores prácticas" o "esto funcionó para mí". Estos son patrones de diseño sin la claridad.

Algunas son solo "cosas que haces habitualmente". Estos son patrones de diseño sin ningún reconocimiento consciente de que te estás repitiendo a ti mismo.

Los patrones de diseño no tienen nada que ver con la debilidad del lenguaje o el estado incompleto. Tienen todo que ver con buenas ideas, conscientemente reutilizadas.

Los patrones de diseño de hoy no son el camino real hacia los idiomas del mañana. El paradigma del lenguaje no avanza a través de una serie de "correcciones de errores a los idiomas anteriores". Si lo hiciera, nunca hubiéramos creado Visual Basic.

Y los patrones de diseño son una herramienta intelectual mucho más grande y más amplia que un conjunto de características de lenguaje de programación simplista.

Creo que Ewan trae un punto fascinante. Tome su ejemplo de "subrutina". En los primeros lenguajes de programación, la idea de pasar parámetros a una subrutina y devolver un resultado era algo que tenía que codificar explícitamente. En los idiomas modernos, está integrado. O para tomar otro ejemplo: If / then / else está integrado en la mayoría, si no en todos, los idiomas modernos. Pero en mis días de ensamblador, tuve que escribir código para lograr eso. No mucho, por supuesto, pero aún así, tenía que escribir realmente la declaración de salto o goto para dar la vuelta al bloque else. Y el hecho de que tuvieras que escribir estas cosas por ti mismo significaba que los diferentes programadores lo harían de maneras ligeramente diferentes, y existía la tentación interminable de ser inteligente y hacerlo un poco diferente en este programa para hacerlo más eficiente u obtener otro supuesta ventaja.

El ejemplo más reciente que viene a la mente son los iteradores. Tienes que escribirlas a mano en C ++ y en las primeras versiones de Java, pero están integradas en Java 5. Se trata sin dudas de azúcar sintáctico, de la misma manera simplemente debes crear funciones de iterador. Personalmente creo que es una buena característica. ¿Mejora radicalmente mi productividad? No.

¿Hay algo que estamos haciendo todo el tiempo que lógicamente debería integrarse en el lenguaje para estandarizarlo y simplificarlo? Una pregunta fascinante No creo que nadie diga seriamente que incluso su idioma favorito es perfecto y que no es posible ninguna mejora. ¿Pero cuál será la dirección del siguiente idioma?

Seguramente algunas características que se han agregado a los idiomas son equipaje adicional inútil. En mi humilde opinión, Java enum hace más de lo necesario, agregan un montón de equipaje sin una buena razón. Estoy seguro de que otros estarán en desacuerdo y dicen que los encuentran increíblemente útiles.

No tengo una conclusión Solo estoy de acuerdo en que es una pregunta fascinante.

Creo que algunos patrones de diseño representan debilidades en el lenguaje y los nuevos lenguajes incorporan patrones existentes en ciudadanos de primera clase. Un ejemplo de un nuevo lenguaje que toma patrones de diseño existentes en otros idiomas (inyección de dependencia, inmutabilidad, etc.) e incorporarlos como características de nivel de lenguaje de primera clase es NOOP de Google.

Existen marcos que facilitan el uso de ciertos patrones en los idiomas, por lo que son más una opción que una necesidad. Existen patrones que, para un determinado proyecto, es posible que simplemente no necesites, por lo que incorporar muchos de ellos como características del idioma principal solo impondría restricciones en lugar de facilitar el trabajo productivo.

He leído en alguna parte algo así como "cuantos más patrones tienes, menos poderoso es tu lenguaje" y esta definición me parece muy agradable.

La razón es IMO clara: si ves un patrón repetido (o tienes que usarlo) significa que es una especie de copiar y pegar en un nivel lógico. Por supuesto, no es tan malo como copiar pegar de las declaraciones, pero sigue siendo redundancia. Todavía me repito una y otra vez.

Cuanto más expresivo sea el lenguaje, más podrá capturar y factorizar esta redundancia transformándola en reutilización en lugar de en reimplementación, y la reutilización será más fácil de leer y comprender en el código fuente.

Cada vez que te encuentras haciendo lo mismo una vez más (incluyendo, por ejemplo, "ok ... vamos a implementar una fábrica abstracta aquí") significa que es algo que debería haberse expresado en un nivel superior.

Por supuesto, a veces puedes tratar de capturar la esencia de algo, pero la reutilización puede ser más fea para leer que la reimplementación (estoy pensando, por ejemplo, en algunas partes de cosas de "alto nivel" de C ++ en <algorithm> ). Esto es IMO, una señal clara de que el lenguaje no es lo suficientemente expresivo.

Los patrones de diseño no son debilidad en los idiomas. Proporcionan soluciones de diseño para problemas recurrentes.

Dado que muchas cosas han ido evolucionando con el tiempo, creo que los Patrones de Integración Empresarial van a ser populares.

Si las diferentes aplicaciones empresariales tienen que comunicarse, estos patrones proporcionan las mejores soluciones.

Integration Styles documentan diferentes formas en que se pueden integrar las aplicaciones, proporcionando una cuenta histórica de las tecnologías de integración. Todos los patrones posteriores siguen el estilo de Mensajería.
Channel Patterns describen cómo se transportan los mensajes a través de un canal de mensajes. Estos patrones son implementados por la mayoría de los sistemas de mensajería comerciales y de código abierto.
Message Construction Patterns describen la intención, la forma y el contenido de los mensajes que viajan a través del sistema de mensajería. El patrón de base para esta sección es el patrón de Mensaje.
Routing Patterns explican cómo se enrutan los mensajes de un remitente al receptor correcto. Los patrones de enrutamiento de mensajes consumen un mensaje de un canal y lo vuelven a publicar, generalmente sin modificaciones, en otro canal según un conjunto de condiciones. Los patrones presentados en esta sección son especializaciones del patrón del enrutador de mensajes.
Transformation Patterns cambian el contenido de un mensaje, por ejemplo, para acomodar diferentes formatos de datos utilizados por el sistema de envío y recepción. Los datos pueden tener que ser agregados, eliminados o los datos existentes pueden tener que ser reorganizados. El patrón base para esta sección es el traductor de mensajes.
Endpoint Patterns describen cómo los clientes del sistema de mensajería producen o consumen mensajes.
System Management Patterns describen las herramientas para mantener en funcionamiento un sistema complejo basado en mensajes, incluido el tratamiento de las condiciones de error, los cuellos de botella de rendimiento y los cambios en los sistemas participantes.

Me pregunto cuánto puedes meter en un idioma antes de que se vuelva demasiado "grande".

Me gusta que el idioma con el que estoy trabajando sea lo suficientemente pequeño como para tenerlo en mi cabeza de una sola vez. Patrones como DI tienen que ver con preocupaciones estructurales; ¿Debería ser eso parte del lenguaje?

¿Cuánta mano en el lenguaje necesita realmente un desarrollador?

En el caso de los Contratos de Código (requiere, asegura), es bueno cuando es una parte de primera clase del lenguaje, pero no es obligatorio. Todavía puede ser parte de una biblioteca.

No, no faltan características o defectos de los idiomas. Pero los lenguajes deberían proporcionar un medio para escribir el código para un patrón útil más fácil que difícil. Ahí es donde las características que proporciona el lenguaje pueden ser una bendición o un obstáculo.

Yo no los llamaría defectos.

Los idiomas de orden superior tratan con conceptos en un nivel más alto que los idiomas de orden inferior. Piénselo en términos de construcción.

Podría construir un edificio a nivel de refinería, fresar madera, fundir acero y armar un edificio de esa manera.

Puede comprar tablas y vigas de acero y construirlas en un edificio.

Puede comprar muros y armaduras prefabricados y construirlos en un edificio.

Podrías comprar un edificio y simplemente comenzar con el interior.

¿Está construyendo un edificio con tablas y vigas que no tienen la característica de pared prefabricada, o es defectuoso de alguna manera?

cada idioma es un conjunto arbitrario de patrones de diseño con sintaxis como notación para los patrones elegidos. para los patrones no elegidos, debe entrometerse dentro de las limitaciones de la sintaxis para expresarlos. la mayoría de los idiomas no permite que su sintaxis cambie mucho para asimilar patrones de nivel superior.

un lenguaje que puede hacer eso ilimitadamente sería uno sin una sintaxis rígida. (o de otra manera, uno que permite asimilar sin problemas cualquier patrón de alto nivel). ver abstracción metalingüística

el que me viene a la mente es scheme / lisp.