¿La Banda de los Cuatro exploró a fondo el "Espacio del Patrón"?

144

Desde que aprendí por primera vez sobre los patrones de diseño de Gang of Four (GoF) , hace al menos 10 años, 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 el Espacio de patrones . Este hipotético Pattern Space consta de todas las soluciones recomendables (conocidas o desconocidas) para problemas comunes de diseño de software orientado a objetos.

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

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

¿Cuales son las razones?

  • ¿Es el conjunto de patrones GoF realmente más completo de lo que creo?

  • ¿Cayó el interés en encontrar nuevos patrones, tal vez porque se descubrió que no son tan útiles en el diseño de software?

  • ¿Algo más?

design-patterns  object-oriented-design 
— Frank Puffer
fuente
49
Los patrones están en todas partes, pero a menudo se usan de una manera robótica e insípida. Por esa razón, creo, la idea del catálogo de patrones se hizo menos popular.
— Usr
66
Espacio de diseño? ¡Que alguien traiga a Mark Rosewater aquí abajo, estadística!
— corsiKa
16
Martin Fowler publicó Patterns of Enterprise Application Architecture en 2003 documentando unos 50 patrones, muchos de los cuales todavía son bastante reconocibles y bien utilizados en la actualidad, por ejemplo, "Data Mapper", "Plugin", "Lazy Load", "Service Layer", etc.
— Brian Rogers el
2
Explorar el espacio de todos los patrones posibles sería como no explorar el espacio de los patrones posibles. Puedes hacer que todo sea un patrón. Si haces que todo sea un patrón, entonces nada es un patrón, ya que la palabra pierde su significado.
— HopefulHelpful
44
@BradThomas: Claro, como con la mayoría de las preguntas interesantes, las personas tienden a tener una opinión determinada. Pero las opiniones se basan, al menos en parte, en hechos, y he encontrado muchos hechos interesantes en las respuestas a esta pregunta que me ayudarán a mí mismo y, con suerte, a otros a repensar sus opiniones y llegar a otras más fundamentadas.
— Frank Puffer

Respuestas:

165

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:

Pero entonces...

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

Esto mucho. El objetivo de los patrones de diseño es mejorar la comunicación entre los desarrolladores, pero si intentas agregar más patrones, llegarás rápidamente al punto en que las personas no podrán recordarlos, o recordarlos mal, o estar en desacuerdo sobre cómo deberían ser exactamente, y la comunicación es no, de hecho, mejorado. Eso ya sucede mucho con los patrones de GoF.

Personalmente, iría aún más lejos: el diseño de software, especialmente el buen diseño de software, es demasiado variado para ser capturado de manera significativa en patrones, especialmente en la pequeña cantidad de patrones que las personas pueden recordar realmente, y son demasiado abstractos para que las personas puedan Realmente recuerdo más que un puñado. Entonces no están ayudando mucho.

Y demasiadas personas se enamoran del concepto e intentan aplicar patrones en todas partes; por lo general, en el código resultante no se puede encontrar el diseño real entre todas las Singletons y las Fábricas abstractas (completamente sin sentido).

— Michael Borgwardt
fuente
50
Opinión controvertida: la fábrica abstracta es un olor a código de todos modos :)
— MetaFight
66
Opinión controvertida, tal vez, pero una opinión tan importante para expresar. Los patrones de diseño corren el peligro de convertirse en un ejemplo de la ropa nueva del emperador, donde todos tenemos miedo de preguntarnos si son útiles. Bien hecho.
— David Arno
18
@MetaFightControversialDesignPatternOnlineOpinionHumanReadableRetortFactory.newInstance().getText();
— corsiKa
11
" El objetivo de los patrones de diseño es mejorar la comunicación entre los desarrolladores " Pensé que los patrones de diseño eran para resolver problemas que los desarrolladores encontraban comúnmente (y con bastante frecuencia de forma independiente). Los estándares mejoran la comunicación y, debido a las fluctuaciones (patrones que surgen de problemas XY, los patrones se consideran antipatrones), muchos no consideran que los patrones de diseño sean estándares. Los patrones de diseño son buenos para señalar la falta de características del lenguaje, y creo que los diseñadores de idiomas están implementando estas soluciones de problemas antes de que se conviertan en patrones de diseño. Sin embargo
— confíes en
11
@ChrisW No entiendo tu punto ... Como dije, el GoF trató de superar las deficiencias de OO, y especialmente las deficiencias de C ++ 98, ya que este era su lenguaje de elección junto con Smalltalk. En realidad, escribieron: "La elección del lenguaje de programación es importante porque influye en el punto de vista de uno. Nuestros patrones asumen características de lenguaje de nivel Smalltalk / C ++, y esa elección determina lo que puede y no puede implementarse fácilmente".
— Shautieh
108

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 el espacio de patrones.

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

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

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

— Robert Harvey
fuente
40
"Los patrones de diseño (en el sentido de GoF) tienen un solo propósito: compensar las deficiencias en el lenguaje de programación que está utilizando". Sigo escuchando esto, pero todavía tengo que verlo justificado. Cada supuesta justificación de la misma solo apunta a un puñado de patrones que son más fáciles de implementar en idiomas con alguna característica, generalmente Visitor y quizás Singleton, y deja la gran mayoría de los patrones intactos, lo que implica que también pueden ser redundantes mejores idiomas ¿Pero cómo lo sabemos? ¿Qué característica del lenguaje hace que Observer sea irrelevante? Cadena de responsabilidad? ¿Compuesto?
— Jules
56
@Jules Las funciones de primera clase solo eliminan una parte considerable de ellas, incluida la Cadena de responsabilidad (es solo la composición de una lista de funciones). La programación reactiva funcional elimina el patrón del observador. El patrón compuesto es solo una definición de monoides menos rigurosamente especificada, y los lenguajes con clases de tipos y un enfoque en las leyes algebraicas brindan herramientas poderosas para trabajar con monoides. Podría enumerar muchos más, pero entiendes la idea.
— Jack
12
@Jules: Creo que el libro original de GoF enumeró el iterador como un patrón, pero ahora su transformación en la función de lenguaje está básicamente completa en cada lenguaje de OOP remoto.
— Kevin
99
@RubberDuck ¿cómo es que tener el patrón ya implementado lo hace obsoleto? Sigue siendo el patrón de diseño que se está implementando. Diferentes conjuntos de características del lenguaje pueden conducir a diferentes implementaciones del patrón, pero el patrón en sí sigue ahí. Los patrones están ahí para facilitar la comunicación dando nombres a las estrategias recurrentes que se usan comúnmente. En este caso, se llaman las clases .NET, ObservableSomething<T>lo que facilita la comprensión de su propósito, ya que utiliza el nombre de patrón comúnmente conocido. Un patrón es una idea, no una implementación exacta.
— nulo
29
@Jules: ¿Qué es un programa? Una solución a un problema recurrente. ¿Qué es un patrón de diseño? Una solución a un problema recurrente. ¿Por qué no es un programa? Porque no podemos expresarlo como un programa. Ergo, un Patrón de diseño es una solución a un problema recurrente que debería ser un Programa, no un Patrón de diseño, pero no puede ser un Programa, porque el lenguaje no es lo suficientemente expresivo como para expresar el Programa. Ejemplo: no hace mucho tiempo, "Llamada de subrutina" era un patrón de diseño. Hoy en día, es una característica del lenguaje.
— Jörg W Mittag
61

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 dar un nombre a algún código que implementa una "porción" particular de funcionalidad. La única forma en que ese nombre proporciona mucho valor real es si puede confiar en que todos sepan lo que significa el nombre, de modo que al usar el nombre, inmediatamente entiendan bastante sobre el código.

Sin embargo, los patrones nunca establecieron la masa crítica que necesitaban para lograr eso. Más bien lo contrario, AAMOF. En los 20 (más o menos) años desde que salió el libro GoF, estoy bastante seguro de que no he visto hasta una docena de conversaciones en las que todos los involucrados realmente conocían suficientes patrones de diseño para su uso para mejorar la comunicación.

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

Demasiados patrones

Creo que el segundo factor principal 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 que es casi imposible decir con certeza real si una clase en particular se ajusta a un patrón u otro (o tal vez a ambos, o tal vez ninguno).

La intención era que pudieras hablar sobre el código en un nivel superior. Podrías etiquetar un fragmento de código bastante grande como la implementación de un patrón particular. Simplemente usando ese nombre predefinido, todos los que escuchan generalmente sabrían tanto como se preocupaban por ese código, por lo que podría pasar al siguiente paso.

La realidad tiende a ser casi lo contrario. 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 supieron o hace mucho tiempo olvidaron exactamente lo que eso significa. Uno de ellos le pide que le recuerde las diferencias exactas entre una Fachada y, por ejemplo, un Proxy. Ah, y la pareja de personas que realmente conocen los patrones pasan el resto de la reunión debatiendo si esto realmente debería considerarse una Fachada o "solo" un Adaptador (con ese tipo todavía insistiendo en que le parece un Proxy).

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

Falta de interés

La mayoría de los patrones de diseño realmente no tratan 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?" Memorizar nombres de patrones para estos (así como los argumentos antes mencionados sobre detalles y demás) simplemente está poniendo mucha energía en cosas que a la mayoría de los programadores simplemente no les importa mucho.

Para decirlo de manera ligeramente diferente: los patrones tratan las cosas que son iguales entre muchos programas, pero lo que realmente hace que un programa sea interesante es cómo es diferente de otros programas.

Resumen

Los patrones de diseño fallaron porque:

  1. No lograron alcanzar la masa crítica.
  2. La diferenciación entre patrones fue insuficiente para garantizar la claridad.
  3. En su mayoría, se ocuparon de partes del código que a casi nadie le importaba de todos modos.
— Jerry Coffin
fuente
2
"... pero lo que realmente hace que un programa sea interesante es cómo es diferente de otros programas". Estoy completamente de acuerdo, pero para eso primero debes tener la misma parte correcta, tal vez solo difieran en algún aspecto trivial. Si se relaja un poco la necesidad de nombrar e identificar patrones, estoy convencido de que uno ve patrones casi por completo. Es solo que casi nunca vienen en su forma pura, sino que siempre están más o menos adaptados al problema en cuestión.
— Trilarion
55
Muy buena respuesta.
— Robert Harvey
44
@Trilarion: Oh, me doy cuenta de que esas partes del código deben escribirse. Son un poco como, digamos, las llantas de tu auto. Prácticamente necesita neumáticos para conducir, pero la mayoría de las personas apenas conocen la marca de neumáticos en su automóvil. Esto les pide que aprendan una terminología especial para un neumático con surcos diagonales asimétricos. Quién sabe, esos podrían haberme salvado la vida una vez, pero todavía no me paso la vida aprendiendo nombres para ellos.
— Jerry Coffin
3
@DavidRicherby: Bien, entonces usemos una versión del lado del productor de la analogía. ¿Importa que John, quien diseña neumáticos para Goodyear, use una palabra para ese tipo de ritmo, pero Pierre, que trabaja para Michelin, usa una palabra completamente diferente? ¿Importa que uno use una palabra que se refiera solo al surco, pero el otro una palabra que se refiera a un neumático completo con surcos horizontales en un lado del centro y surcos diagonales en el otro?
— Jerry Coffin
2
@immibis: Yo diría que sí, han fallado. Yo diría que hay menos de media docena de patrones que la mayoría de los programadores reconocen. Singleton es bien conocido, pero en realidad rara vez es aplicable (en el mejor de los casos). El nombre de "fábrica" era de uso común mucho antes de "patrones" vinieron (recuerdo su uso en la década de 1970 o muy a principios de 1980). Se suponía que los patrones formaban un vocabulario, pero actualmente son como mi vocabulario en griego: lo suficiente como para (posiblemente) meterme en problemas, pero ciertamente no lo suficiente como para ordenar un menú, y mucho menos mantener una conversación significativa.
— Jerry Coffin
35

Faltan abstracciones en los patrones, se abstraen los patrones simples, no se reconocen los patrones complejos, por lo que los patrones no son útiles (excepto algunos 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 una señal, al menos para mí, de que estoy usando abstracciones que no son lo suficientemente potentes, 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 deberías usar una mejor abstracción. Si no tiene una mejor abstracción, utilice 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.
También los patrones simples a menudo se abstraen fácilmente 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 se puede reconocer como un patrón.

— Siphor
fuente
2
Personalmente, de alguna manera me gusta mucho esta idea. Pero entonces, el código debe ser legible por humanos y personas como patrones. Los patrones nos ayudan a encontrar el camino. Eliminar todos los patrones de nuestro código lo hará ilegible.
— Frank Puffer
2
@Frank Creo que de dónde viene PG es que un patrón es un "olor" de una función subyacente que puedes abstraer, y el hecho de que no lo hayas convertido en una función o macro es lo que está causando la repetición, como Si no tuviera una String.replacefunción, podría imaginarla apareciendo como un patrón, pero es mejor escribirla una vez en lugar de continuar reimplementándola. De acuerdo en que si usted no nombra a estas cosas correctamente, haría más difícil de leer, pero cuando se hace bien, el código se lee más declarativa de la OMI (por ejemplo, el getOrElseestilo de mónadas opción vs comprobación null)
— anotherdave
11
La cita de Paul Graham fue sobre mantener sus soluciones SECAS, lo cual es diferente de la idea del "patrón" de GoF. La idea de GoF era dar nombres a las soluciones de uso común. Ya estábamos haciendo eso mucho antes de que GoF publicara su libro. Por ejemplo, puedo decirle a mi compañero de trabajo que voy a usar una cola , y mi compañero de trabajo sabe de inmediato de lo que estoy hablando sin tener que explicar los detalles de lo que hace una cola o cómo funciona. Pero, vea la excelente respuesta de Michael Borgwardt, arriba.
— Solomon Slow
10
En mi opinión, esta respuesta no comprende qué son los patrones. Un patrón de diseño es una solución frecuente para un problema común. No es una duplicación de código. Digamos, toma un iterador. Usted resuelve el problema de abstraer el contenedor para poder revisar los elementos que contiene, independientemente de cuál sea el contenedor. Por lo tanto, crea una clase de iterador que hace eso para cada uno de sus contenedores y hace que implementen una interfaz común. ¿Qué hay que resumir aquí? Un iterador ya es una abstracción. Y, por supuesto, se implementa de manera diferente para todos los contenedores, por lo que no hay duplicación de código.
— Malcolm
3
La parte clave de la cita de Graham a menudo es que estoy generando a mano las expansiones de alguna macro que necesito escribir. Esto hace referencia a las macros de Lisp específicamente. Solo hay tanta abstracción que se puede hacer sin macros.
— Bart van Nierop
13

Si bien estoy de acuerdo con lo que otros respondieron aquí, personalmente creo que una razón principal para un número no creciente de patrones es que los patrones pierden su significado cuando hay innumerables. Lo bueno de estos pocos patrones es que cubren muchos dominios problemáticos de manera estándar. Si te enfocas en un dominio de patrones sin fin, terminarás sin ningún patrón. Es un poco como "¿Cuánto dura la línea costera de una isla?". Si mides en un mapa, vienes 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 mareas y a nivel atómico?).

— qwerty_so
fuente
1
Correcto, los patrones solo pueden funcionar si no hay demasiados. Pero, ¿por qué los GoF siguen siendo los más populares? Algunos de ellos ahora son considerados como antipatrones por muchas personas (Singleton, Builder, etc.). Esto debería dejar espacio para patrones nuevos y más útiles sin aumentar el número total.
— Frank Puffer
2
Supongo que es como los 10 mandamientos. La fuente está a solo 2 caracteres de distancia (GOF, GOE, DIOS) xD
— qwerty_so
99
Sí, y a veces parece que la ingeniería de software moderna se relaciona con GoF como los escolásticos medievales se relacionan con Aristóteles.
— Frank Puffer
11

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

El auge de los lenguajes de tipo dinámico.

Cuando el libro salió por primera vez, hubo una discusión seria de que Java era demasiado lento para hacer un trabajo real. Ahora, Java se usa con frecuencia sobre lenguajes más expresivos debido a su velocidad. Quizás Ruby, Python, JavaScript, y otros aún son 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 JavaScript al menos en realidad se está volviendo más rápido a pesar de tener más funciones incluidas en cada versión.

El libro original de GoF tenía los patrones en smalltalk y c ++, y si la memoria sirve, los patrones siempre fueron más cortos en smalltalk y, a veces, significativamente. 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 tipado estáticamente (como el AbstractFactory ya discutido, en el que 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.

— Jared Smith
fuente
10

Se hizo pasar. Decenas, 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, a medida que los editores y autores intentaron subirse (o crear) otro carro más. Tengo un estante de ellos. Nunca consulté desde el primer escaneo, y sí, fui un imbécil, porque había poco o nada de uso real o eso no se conocía bien (ver, por ejemplo, Type Object, que no es más que la 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, me dieron instrucciones de volver a redactar mi texto como un patrón de diseño.Historia verdadera. Lo que también muestra otra deficiencia del proyecto: ningún mecanismo de revisión o exclusión o rechazo.

De hecho, el GoF en realidad no intentó "explorar a fondo los patrones de diseño". Más bien, se involucraron en un proyecto mucho más grande: introducir el 'lenguaje de patrones' en CS, con todos sus extraños arcanos de notación de Fuerzas, Participantes, etc., que simplemente fallaron, porque fue fundamentalmente mal concebido, además de no tener sentido.

Lo que ellos hicieron cumplir, que era útil, era dos cosas:

  • publicar varios trucos útiles, como el patrón Visitante
  • proporcione un conjunto estándar de nombres que se ha quedado en gran parte pegado: Fábrica, Adaptador, Iterador, ... Si observa CORBA, que se diseñó inmediatamente antes, verá el valor de esto: todo tipo de nombres "extranjeros" como Interceptor , Siervo, Corredor, ...

Otro concepto útil que surgió fue el 'antipatrón', por ejemplo, 'iniciar sesión y lanzar'. El proyecto, como muchas modas en CS, se descarriló por su propio evangelismo y por ser adoptado erróneamente como otra religión de CS, y siguió el camino de la mayoría de esas religiones: útil en partes, pero ciertamente 'sin bala de plata' ((c ) Fred Brooks, 1965). Es triste que tengamos que redescubrir eso cada pocos años realmente.

— usuario207421
fuente
¿Sigue siendo triste si resultó en esta discusión (y todo lo que eso conlleva)
— R3wt
1
@ r3wt Non sequitur. Lo que dije es triste es la debilidad de la industria de TI por pensar que cada nuevo desarrollo será la mítica bala de plata y, por cierto, por destrozar parte de su propio trabajo anterior.
— user207421
2
Míralo desde una perspectiva diferente. No es triste para mí leer tu respuesta, aprender a no repetir el error. así que lo que das por sentado es realmente muy útil para los demás.
— r3wt
6

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

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

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

Presumiblemente, los "solo 12 patrones adicionales enumerados en el artículo de Wikipedia" tampoco son una colección completa: es decir, hay otros documentados en otros lugares, por ejemplo, en los libros de PLoP y quizás también en otros lugares.

— ChrisW
fuente
Sí, puede encontrar descripciones de cientos de patrones si los busca. Pero ninguno de estos parece ser tan popular como los GoF.
— Frank Puffer
Fue porque me gustó leer el libro GoF que leí más (libros) cuando se publicaron (más adelante).
— ChrisW
1
@FrankPuffer Apuesto a que los patrones son populares, incluso si los nombres no lo son.
— dcorking
5

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 usar. La contribución principal del libro fue dar un nombre bien definido a los patrones que eran de uso común por 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, del mismo modo que esperaría que un programador de WPF conozca los patrones de diseño para las "Propiedades de dependencia", o un "Programador de SQL" para conocer el patrón de diseño para usar disparadores para Crear datos de auditoría.

Sin embargo, no los consideramos "patrones de diseño" debido a que solo se utilizan con una tecnología.

Algunos libros de patrones de diseño más modernos son "Refactoring, Improving the Design of Existing Code (Martin Fowler)" y "Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin) ". Ambos libros presentan los contenidos como transformaciones que usted hace a su código actual, en lugar de como "diseño reutilizable preenvasado", sin embargo, son tanto "patrones de diseño".

— Ian
fuente
3

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

http://www.informit.com/articles/article.aspx?p=1404056

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

Erich: Hicimos este ejercicio en 2005. Aquí hay algunas notas de nuestra sesión. Hemos descubierto que los principios de diseño orientado 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 cambiar la categorización y, en particular, qué patrones descartar.

Cuando discutimos qué patrones descartar, descubrimos que todavía los amamos a todos. (En realidad no, estoy a favor de dejar caer 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 mosca deberían pasar a una categoría separada a la que nos referimos como "Otro / Compuesto", ya que realmente son bestias diferentes a los otros patrones. El Método de Fábrica se generalizaría 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 (ver "Objeto de extensión" en Lenguajes de patrones del diseño del 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, Constructor, Inyección de dependencias
    • Periférico: Fábrica abstracta, Visitante, Decorador, Mediador, Tipo de objeto, Objeto nulo, Objeto de extensión
    • Otros: peso mosca, intérprete
— akuhn
fuente
¿Por qué me rechazas? Por favor explique en un comentario para que pueda mejorar la respuesta.
— akuhn
3

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

Cuando aprende esa habilidad, se da cuenta de que no necesita recordar los detalles exactos de cada patrón, ya que siempre puede cortar la solución que está implementando de la manera que mejor se adapte a su propósito. Entonces, la idea de escribir más y más patrones parece muy académica y sin sentido.

— lud1977
fuente
Buen punto, sin embargo, dudo que muchas personas entiendan el libro (o los patrones en general) de esa manera.
— Frank Puffer
@ lud1977 si no registramos el historial, ¿qué impide que el futuro caiga en las mismas trampas? por lo tanto, siempre debe ser registrado. No es inútil.
— r3wt
2

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

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

El libro 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 esta búsqueda ). 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. En cambio, hay tantos que nadie puede memorizarlos a todos y la mayoría de los programadores reconocen solo unos pocos. La gran promesa del lenguaje de patrones común se rompe en este momento.

— iluwatar
fuente
-1

Probablemente hay muchas estructuras en las que aún no se ha 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 todavía existen en el diseño de los idiomas. Por lo tanto, pueden ser ignorados hoy, pero eso no los hace sin importancia.

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

Entonces no, no creo que el espacio de patrones 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 se construyen en los niveles superiores prestarán atención a los detalles de cómo se construyó la torre. .

— Tim
fuente
-2

Los patrones son infinitos ... Puede ajustar cada patrón o mezclar y combinar para crear nuevos ... Los patrones de integración empresarial también están bien definidos ... así que sí, gof se molestó en documentar patrones usando uml y creó un estándar para explicarlos ... Pero para cada dominio los patrones evolucionan y también cambian para lenguaje expresivo como python o scala.

— Marut Singh
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.