¿Exploró a fondo la Banda de los Cuatro "Espacio de patrones"?

Cuando salió el Libro, mucha gente pensó de esa manera, y hubo muchos esfuerzos para crear "bibliotecas de patrones" o incluso "comunidades de patrones". Todavía puedes encontrar algunos de ellos:

• "Pattern Community" , WikiWikiWeb
• "El grupo de estudio de patrones de diseño de la ciudad de Nueva York" , Industrial Logic
• "Catálogo de patrones" , The Hillside Group

Pero entonces ...

  

¿Se redujo el interés en encontrar nuevos patrones, tal vez porque no son realmente tan útiles en el diseño de software?

Esto, mucho. El punto de los patrones de diseño es mejorar la comunicación entre los desarrolladores, pero si intenta agregar más patrones, rápidamente llegará al punto en el que las personas no los pueden recordar, no los recuerdan o no están de acuerdo en lo que hacen exactamente. Debería parecer, y la comunicación no está, de hecho, mejorada. Eso ya sucede mucho con los patrones GoF.

Personalmente, iría aún más lejos: el diseño de software, especialmente el diseño de software bueno, es demasiado variado para ser capturado de manera significativa en patrones, especialmente en la pequeña cantidad de patrones que la gente realmente puede recordar, y son demasiado abstractos para que la gente realmente recuerde más de un puñado. Así que no están ayudando mucho.

Y demasiada gente se enamora del concepto y trata de aplicar patrones en todas partes. Por lo general, en el código resultante no se puede encontrar el diseño real entre todas las Fábricas Singletons y Abstractas (sin significado alguno).

  

Tengo la impresión de que estos 23 patrones deberían ser solo una pequeña muestra de algo mucho más grande que me gusta llamar Espacio de patrones.

Esta es la terrible suposición que se propaga por los programadores neófitos de todo el mundo, los programadores que piensan que pueden escribir un programa simplemente al unir patrones de software. No funciona de esa manera. Si existe ese "espacio de patrón", puede asumir que su tamaño es infinito.

Los patrones de diseño (en el sentido de GoF) solo tienen un propósito: para compensar las deficiencias en el lenguaje de programación que está utilizando.

Los patrones de diseño no son universales ni completos. Si cambias a un lenguaje de programación diferente, más expresivo, la mayoría de los patrones en el libro de GoF se vuelven innecesarios e indeseables.

Creo que hay tres factores que entran en juego aquí.

Falta de masa crítica

Primero, un patrón es básicamente poco más que darle un nombre a un código que implementa una "parte" particular de funcionalidad. La única forma en que ese nombre proporciona mucho valor real es si puede depender de que todos sepan lo que significa el nombre, por lo que al usar el nombre, entienden inmediatamente mucho sobre el código.

nunca establecieron la masa crítica que necesitaban para lograrlo. Más bien al contrario, AAMOF. En los 20 (o así) años transcurridos desde que salió el libro de GoF, estoy bastante seguro de que no he visto tantas como una docena de conversaciones en las que todos los involucrados realmente sabían suficientes patrones de diseño para mejorar su comunicación.

Para decirlo de forma un poco más extraña: los patrones de diseño fallaron específicamente porque fallaron.

Demasiados patrones

Creo que el segundo factor importante es que, en todo caso, inicialmente nombraron demasiados patrones. En un buen número de casos, las diferencias entre los patrones son lo suficientemente sutiles como para que sea casi imposible decir con certeza real si una clase en particular se ajusta a un patrón u otro (o tal vez ambos, o tal vez ninguno).

La intención era poder hablar sobre el código en un nivel superior. Sería capaz de etiquetar una gran parte del código como la implementación de un patrón particular. Simplemente al usar ese nombre predefinido, todos los que escuchan suelen saber todo lo que les importa sobre ese código, por lo que podría pasar a la siguiente cosa.

La realidad tiende a ser casi la opuesta. Digamos que estás en una reunión y diles que esta clase en particular es una fachada. La mitad de las personas en la reunión nunca lo supieron o hace mucho que han olvidado lo que eso significa. Uno de ellos le pide que le recuerde la diferencia exacta entre una fachada y, por ejemplo, un proxy. Ah, y el par de personas que realmente saben patrones pasan el resto de la reunión debatiendo si esto realmente debería considerarse una Fachada o "solo" un Adaptador (con ese único individuo insistiendo en que le parece un Proxy).

Teniendo en cuenta que su intención era solo decir: "este código no es muy interesante; sigamos adelante", tratar de usar el nombre de un patrón solo agrega distracción, no valor.

Falta de interés

La mayoría de los patrones de diseño no tratan realmente con las partes interesantes del código. Se ocupan de cosas como: "¿Cómo creo estos objetos?" Y "¿Cómo consigo que este objeto hable con ese objeto?" Memorizar nombres de patrones para estos (así como los argumentos antes mencionados sobre los detalles) es simplemente poner mucha energía en las cosas que a la mayoría de los programadores no les importa mucho.

Para decirlo de forma ligeramente diferente: los patrones se ocupan de las cosas que son iguales entre muchos programas, pero lo que realmente hace que un programa sea interesante es la forma en que es diferente de otros programas.

Resumen

Los patrones de diseño fallaron porque:

1. No lograron alcanzar una masa crítica.
2. La diferenciación entre los patrones fue insuficiente para garantizar la claridad.
3. En su mayoría trataban con partes del código que casi nadie realmente se preocupaba de todos modos.

A los patrones les faltan abstracciones, los patrones simples se abstraen, los patrones complejos no se reconocen, por lo que los patrones no son útiles (excepto unos pocos de alto nivel).

Creo que Paul Graham lo dijo mejor:

  

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 un signo, al menos para mí, de que estoy usando abstracciones que no son lo suficientemente poderosas, a menudo que estoy generando a mano las expansiones de alguna macro que necesito escribir.

Cuando reconoces un patrón en tu código, significa que algo se repite y debes usar una mejor abstracción. Si no tiene una mejor abstracción, use el patrón como solución alternativa. Debido a que los lenguajes de programación más nuevos proporcionan mejores abstracciones, los patrones se vuelven mucho menos útiles.
Además, los patrones simples a menudo son fácilmente abstractos y los patrones complejos rara vez se reconocen.
Cuando un patrón se reemplaza por una abstracción, no significa que el concepto detrás del patrón desaparezca, sino que el concepto se puede escribir explícitamente en lugar de indirecto y que ya no es especial en comparación con otro código y ya no es reconocible como un patrón.

Si bien estoy más de acuerdo con lo que otros respondieron aquí, personalmente creo que la razón principal para que no haya un número creciente de patrones es que los patrones pierden su significado cuando hay innumerables. Lo bueno de estos pocos patrones es que cubren muchos dominios de problemas de manera estándar. Si se enfocara en un dominio de patrones sin fin, terminaría sin ningún patrón. Es un poco como "¿cuánto dura la costa de una isla?". Si usted mide en un mapa, viene con un número decente. Pero si trata de ser más exacto y llega a una resolución más fina, encontrará que la longitud aumenta cada vez más hasta el infinito (o incertidumbre; ¿cómo mediría el borde exacto con las mareas y en el nivel atómico?).

Algo que ninguna de las otras respuestas menciona que también es relevante:

El auge de los lenguajes de tipo dinámico.

Cuando salió el libro por primera vez, hubo una seria discusión de que Java era demasiado lento para realizar un trabajo real. Ahora, Java se usa con frecuencia en lenguajes más expresivos porque de su velocidad. Tal vez Ruby, Python, JavaScript, y otros son todavía demasiado lentos para algunas clases importantes de aplicaciones, pero en general son lo suficientemente rápidos para la mayoría de los propósitos. Y, al menos, JavaScript se está volviendo más rápido a pesar de tener más funciones en cada versión.

El libro original de GoF tenía los patrones tanto en smalltalk como en c ++, y si la memoria sirve, los patrones siempre fueron más cortos en smalltalk y, a veces, de manera significativa. Algunas de las características de los patrones de diseño clásicos son realmente formas de agregar características dinámicas a un sistema tipificado estáticamente (como el AbstractFactory ya discutido, en el que se crea una instancia de la clase correcta basada en datos de tiempo de ejecución). Otros son mucho más cortos en lenguajes dinámicos que simplemente se funden en el uso idiomático del lenguaje mismo.

sucedió . Docenas, si no cientos, de libros se publicaron en lo que parecía un intento de reducir la totalidad de la informática para diseñar patrones, mientras los editores y autores intentaban subirse (o crear) otro carro. Tengo un estante de ellos. Nunca se consultó desde el primer escaneado, y sí, fui un imbécil, porque había poco o nada allí de un uso real o que ya no era muy conocido (ver, por ejemplo, Tipo Objeto, que no es más que una tercera forma normal expresada sobre una docena de páginas en lugar de un párrafo), y porque, obviamente, cuantos menos patrones, mejor: un punto que eludió a la mayoría de los practicantes. De hecho, cuando publiqué una refutación de Type Object, se me indicó que modificara mi texto como un patrón de diseño. Verdadera historia. Lo que también muestra otra deficiencia del proyecto: ningún mecanismo de revisión, exclusión o rechazo.

De hecho, el GoF en realidad no intentó "explorar a fondo los patrones de diseño". Más bien, se comprometieron en un proyecto mucho más grande: introducir un 'lenguaje de patrones' en CS, con todos sus extraños arcanos notacionales de Fuerzas, Participantes, etc., que simplemente fallaron, porque fue fundamentalmente erróneo, así como inútil.

Lo que lograron , que fue útil, fue dos cosas:

• publica varios trucos útiles como el patrón de visitante
• proporcione un conjunto estándar de nombres que se ha atascado en gran medida: Fábrica, Adaptador, Iterador, ... Si observa CORBA, que se diseñó de antemano, verá el valor de este: todo tipo de nombres "extranjeros" como Interceptor, Servidor, Broker, ...

Otro concepto útil que surgió fue el "antipatrón", por ejemplo, 'registrar y lanzar'. El proyecto, al igual que muchas otras modas en CS, se descarriló por su propio evangelismo y por ser adoptado de manera equivocada como otra religión CS, y siguió el camino de la mayoría de las religiones: útil en algunas partes, pero ciertamente "sin bala de plata" ) Fred Brooks, 1965). Es triste que tengamos que seguir redescubriendo eso cada cierto tiempo.

Había / hay varios libros titulados PLoP ( Lenguajes de patrones de diseño de programas ) que son cada una antología de artículos presentados en una conferencia anual .

Al leer los libros, encontré que algunos de los patrones eran interesantes y nuevos para mí, algunos de ellos estándares (por ejemplo, "medio objeto más protocolo").

Así que no, la colección de GoF no fue exhaustiva e inspiró / inspiró a las personas a recopilar / describir / descubrir / inventar nuevas.

Los "solo 12 patrones adicionales enumerados en el artículo de Wikipedia" probablemente tampoco son una colección completa: es decir, hay otros documentados en otra parte, por ejemplo, en los libros de PLoP y tal vez en otros lugares.

El libro Gang of Four (GoF) contiene la mayoría de los patrones que un programador experimentado en un lenguaje no funcional tiene en su cinturón de herramientas. Es como el conjunto básico de herramientas que todos los constructores saben cómo usar. La contribución principal del libro fue dar un nombre bien definido a los patrones que eran de uso común por parte de los programadores más experimentados en ese momento y, por lo tanto, ayudar a la comunicación entre los programadores que discuten las opciones de diseño.

Usted espera que un electricista tenga algunas herramientas que un constructor normal no tiene, como también esperaría que un programador de WPF conozca los patrones de diseño para "Propiedades de dependencia", o un "Programador de SQL" para conocer el patrón de diseño de utilizando desencadenantes para crear datos de auditoría.

Sin embargo, no pensamos que estos sean “patrones de diseño” debido a que solo se utilizan con una tecnología.

Algunos libros de patrones de diseño de módem más son "Refactorización, mejora del diseño de código existente (Martin Fowler)" y “Código limpio: Manual de Agile Software Craftsmanship (Robert C. Martin) " Ambos libros presentan los contenidos como transformaciones que realiza en su código actual, en lugar de" diseño reutilizable pre enlatado ", sin embargo, son tanto" patrones de diseño ".

Los patrones reales en el libro a veces son realmente útiles, pero en realidad son solo ejemplos de una herramienta más poderosa que le brinda el libro: una comprensión profunda de cuándo y dónde es mejor cortar el código monolítico en partes independientes separadas y reguladas por una interfaz.

Cuando aprendes esa habilidad, te das cuenta de que no necesitas recordar los detalles exactos de cada patrón, ya que siempre puedes cortar la solución que estás implementando de la manera que mejor se adapte a su propósito. Así que la idea de escribir más y más patrones parece muy académica y sin sentido.

  

Así que esperaba la cantidad de patrones de diseño conocidos y documentados para   crecer significativamente.

     

No sucedió. Más de 20 años después de que salió el libro de GoF,   solo 12 patrones adicionales están listados en el artículo de Wikipedia, la mayoría   De los cuales son mucho menos populares que los originales. (No lo hice   incluir los patrones de concurrencia aquí porque cubren un específico   tema.)

El libro de GoF y Wikipedia no son la única fuente de patrones de diseño conocidos. Si solo busca "patrones de diseño" en Amazon.com, obtendrá cientos de libros (intente esto search ). Supongo que solo enumeran el patrón más conocido en el artículo de Wikipedia .

Entonces, el problema no es que no haya suficientes patrones de diseño documentados. Más bien, hay tantos que nadie puede memorizarlos todos y la mayoría de los programadores reconocen solo unos pocos. La gran promesa del lenguaje de patrón común se rompe en este punto.

Aquí hay una entrevista con Erich Gamma donde reflexiona sobre su selección de patrones y lo que cambiarían hoy (bueno, hoy a partir de hace 10 años, jaja).

enlace

  

Larry: ¿Cómo refactorizarías los "Patrones de diseño"?

     

Erich: Hicimos este ejercicio en 2005. Aquí hay algunas notas de nuestra sesión. Hemos encontrado que los principios de diseño orientados a objetos y la mayoría de los patrones no han cambiado desde entonces. Queríamos cambiar la categorización, agregar algunos miembros nuevos y también eliminar algunos de los patrones. La mayor parte de la discusión fue sobre el cambio de categorización y, en particular, sobre qué patrones abandonar.

     

Cuando discutimos qué patrones dejar, descubrimos que todavía los amamos a todos. (No realmente, estoy a favor de dejar de usar Singleton. Su uso es casi siempre un olor a diseño).

     

Así que aquí están algunos de los cambios:

     

• El intérprete y el peso de la mosca deben ser movidos a una categoría separada a la que nos referimos como "Otros / Compuestos" ya que realmente son bestias diferentes de los otros patrones. El Método de Fábrica sería generalizado a Fábrica.
  
• Las categorías son: Core, Creational, Peripheral y Other. La intención aquí es enfatizar los patrones importantes y separarlos de los que se usan con menos frecuencia.
  
• Los nuevos miembros son: Objeto nulo, Objeto de tipo, Inyección de dependencia y Objeto / Interfaz de extensión (consulte "Objeto de extensión" en Lenguajes de patrones del Diseño de programa 3, Addison-Wesley, 1997).
  
• Estas fueron las categorías:      
  • Núcleo: Compuesto, Estrategia, Estado, Comando, Iterador, Proxy, Método de plantilla, Fachada
    
  • Creacional: Fábrica, Prototipo, Generador, Inyección de dependencia
    
  • Periférico: fábrica abstracta, visitante, decorador, mediador, tipo de objeto, objeto nulo, objeto de extensión
    
  • Otro: peso mosca, intérprete
    
  

Probablemente hay muchas estructuras que aún no se han pensado. Mientras las personas desarrollen software, habrá desafíos de diseño que superar. Algunos de ellos pueden resolverse utilizando nuevos patrones inteligentes que otros podrían utilizar.

Los lenguajes de programación se han desarrollado y progresado para abstraer los patrones más utilizados. Esos patrones aún existen en el diseño de los lenguajes. Por lo tanto, pueden ignorarse hoy, pero eso no los hace poco importantes.

¿El conocimiento de cómo construir una casa repentinamente no es importante una vez que tenemos robots que pueden hacerlo por nosotros? Yo diría que no, no lo es. Es menos relevante, seguro, y probablemente mucho menos gratificante de estudiar, ya que la demanda se redujo drásticamente y nadie más la está estudiando.

Así que no, no creo que el espacio del patrón como lo llamas se haya agotado. Como señaló otra respuesta, es probable que sea infinito. Pero a medida que disminuye la demanda de diseño de sistemas, a medida que aumentamos la altura de nuestra torre de abstracción y el poder de nuestros lenguajes de programación, cada vez menos personas que construyen en los niveles superiores prestarán atención a los detalles de cómo se construyó la torre. .

Los patrones son infinitos ... Puedes modificar cada patrón o combinar n para crear nuevos. Los patrones de integración empresarial también están bien definidos ... así que sí, se preocuparon de documentar patrones utilizando uml y crearon un estándar para explicarlos. .. Pero para cada dominio, los patrones evolucionan y también cambian para el lenguaje expresivo como python o scala ..