Como se indica en el primer párrafo, el patrón de diseño es más un artefacto de ingeniería de software que de ciencia informática . O elija la tercera opción: computación . — Comentario anterior sin firmar agregado por Kejia ( discusión • contribuciones ) 18:16, 12 de diciembre de 2010 (UTC)
Quizás en los próximos días, a menos que alguien esté razonablemente en desacuerdo. -- Daydreamer302000 ( discusión ) 11:29 8 jun 2009 (UTC)
Creo que los patrones de diseño deberían incluir ejemplos de todo el lenguaje, lo cual es muy útil para entender el patrón. —Comentario anterior sin firmar añadido por 207.46.92.16 (discusión • contribuciones ) 02:19, 10 de junio de 2009
Las numerosas páginas dedicadas a patrones de diseño específicos tienen un exceso crónico de ejemplos. Muchas páginas son más del 80% de ejemplos; ¡al menos un patrón tiene ejemplos en 13 lenguajes con un total de 16 ejemplos! Si bien algunos ejemplos son diferentes en formas importantes entre familias de lenguajes (como fuertemente tipados versus tipados dinámicamente), tengo la fuerte sensación de que los defensores de los lenguajes están agregando ejemplos similares que restan valor a la explicación del patrón en particular. Creo que Java es probablemente el mejor lenguaje de ejemplo para patrones de diseño orientados a objetos, ya que los ejemplos de Java no estarán abarrotados de código de administración de memoria, sino que están fuertemente tipados, por lo que está claro qué hereda qué. Divulgación completa: mis propios lenguajes de elección personal son C++ y Python y no estoy demasiado familiarizado con Java. He cambiado algunos ejemplos de algoritmos de pseudocódigo a Python cuando un ejemplo de Python funcional podría ser casi tan fácil de entender como el pseudocódigo. Sin embargo, para los patrones de diseño orientados a objetos, realmente creo que un lenguaje ampliamente utilizado fuertemente tipado y recolectado de basura es el más apropiado, y eso me deja con Java.
Si la gente tiene la firme convicción de que hay que tener ejemplos en todos los idiomas posibles, yo diría que los ejemplos deberían estar separados en páginas separadas o en wikilibros. Pero, sin duda, 16 ejemplos en 13 idiomas no es la mejor manera de describir el patrón singleton . —Ben FrantzDale ( discusión ) 13:47, 8 de abril de 2009 (UTC)
Acabo de darme cuenta de que esto ha molestado al menos a un usuario no registrado. No fui yo, pero estoy de acuerdo en que deberíamos crear un lugar para ello sin bombardear todo ese contenido hasta que desaparezca. Gracias. 122.29.47.35 (discusión) 11:07 13 abr 2009 (UTC) Lo siento, me refería específicamente al artículo de Singleton, pero sí, supongo que se aplica a todos. 122.29.47.35 (discusión) 11:08 13 abr 2009 (UTC)
En la página de patrones de visitantes , he movido la plantilla de wikilibros a la sección de ejemplos y he modificado su texto para indicar más claramente que hay más ejemplos allí. ¿Está bien que todas las páginas afectadas se editen de forma similar? -- Jokes Free4Me ( discusión ) 19:53, 15 de abril de 2009 (UTC)
Hola, acabo de agregar
D, Schmidt (2000). Arquitectura de software orientada a patrones, volumen 2: Patrones para objetos concurrentes y en red . John Wiley & Sons. ISBN 0-471-60695-2. {{cite book}}
: Parámetro desconocido |coauthors=
ignorado ( |author=
sugerido) ( ayuda )
Creo que muchos de los patrones cuncurrentes de la tabla provienen de este libro, sería bueno agregar una columna para eso. Saludos. 122.29.47.35 (discusión) 11:22 13 abr 2009 (UTC)
No estoy seguro de considerar la encapsulación, la herencia y las excepciones como patrones de diseño. La encapsulación y la herencia son instrucciones generales para estructurar el código más que patrones, elementos reutilizables del software. Son filosofías más que patrones o planos. Los patrones (no limitados a la ciencia informática) deben ser unánimemente reconocibles. Por ejemplo, el uso de la proporción áurea en un diseño arquitectónico es indiscutible. Nunca he visto que se utilicen "patrones fundamentales" en ningún lugar fuera de esa presentación de conferencia universitaria citada y el libro que cita, "Program Development in Java" de Barbara Liskov. Me parece que el autor deseaba acuñar un nuevo término; tal vez alguien que lo lea pueda proporcionar otra opinión. Mi [consulta] arrojó pocos resultados relevantes. ¿El término "patrón fundamental" ha ganado aceptación de la comunidad o uso popular? Y si es así, ¿califican (y por qué) la encapsulación y la herencia? ¿Alguna idea? Además, la página Patrón fundamental enumera el patrón Proxy , el patrón Facade y el patrón Composite ; los tres se enumeran como patrones estructurales en esta página ; y no se mencionan la herencia ni la encapsulación. dm yers t urnbull ⇒ discusión 03:59, 4 de junio de 2009 (UTC)
Quitaría todo lo que haga referencia a "patrones fundamentales". Sencillamente, no pertenecen al grupo. "Design Patterns" (ISBN-10: 0201633612) tiene 15 años y es, sin duda, una de las obras fundamentales. Todavía se sigue imprimiendo. Cataloga unos 15 patrones, desde la fábrica hasta el visitante. Eso es lo que normalmente abarca el término y lo que Wikipedia debería documentar.
¿Cómo distinguir entre un patrón y algo como la herencia? No existe un soporte directo para un patrón en ningún lenguaje. Por eso son patrones: porque muchos programadores, al enfrentarse a diversos problemas en una variedad de lenguajes, encontraron formas similares (patrones) de abordarlos.
Sin embargo, no estoy de acuerdo con la otra advertencia que sugiere que las críticas deberían integrarse en el documento. La "otra escuela de pensamiento" debería tener su propia sección para permitir que la sección principal exponga sus argumentos.
Tiene su propia página en Wikipedia como patrón de creación. —Comentario anterior sin firmar añadido por 208.127.236.194 ( discusión ) 15:00, 14 agosto 2009 (UTC)
Como se indica en la página de "discusión" de Multiton, Multiton parece ser intercambiable con el "patrón Flyweight" (los ejemplos de código son intercambiables). Parece como si fuera solo un nombre alternativo para el mismo patrón, colocado en una categoría diferente. — Comentario anterior sin firmar agregado por 38.70.1.35 (discusión) 04:20, 5 de septiembre de 2012 (UTC)
¡Estos patrones pertenecen aquí y también deberían tener su propia página en la wiki! ¿Qué opinas? Más información aquí: Patrones de integración
Un anónimo eliminó la sección de críticas [3] con el comentario
El material a eliminar es
Crítica
En el campo de la informática existen algunas críticas respecto al concepto de patrones de diseño.
Soluciones alternativas para las funciones del lenguaje faltantes
Los usuarios de lenguajes de programación dinámica han discutido muchos patrones de diseño como soluciones a las limitaciones de lenguajes como C++ y Java . [1]
Por ejemplo, el patrón Visitor no necesita implementarse en un lenguaje que admita métodos múltiples . El propósito de Visitor es agregar nuevas operaciones a clases existentes sin modificarlas. En C++, una clase se declara como una estructura sintáctica con un conjunto específico y cerrado de métodos. En un lenguaje con métodos múltiples , como Common Lisp , los métodos de una clase están fuera de la estructura de la clase y se pueden agregar nuevos métodos sin modificarla.
De manera similar, el patrón Decorator equivale a implementar la delegación dinámica , como la que se encuentra en Common Lisp, Objective-C , Self y JavaScript .
Muchos patrones implican una orientación a objetos o, de manera más general, un estado mutable, por lo que carecen de sentido en el estilo de programación funcional , en el que los datos son inmutables o se tratan como tales. Por ejemplo, el patrón Iterator es una generalización de los bucles "for" , una noción inherentemente imperativa .
No difiere significativamente de otras abstracciones.
Algunos autores [¿ quiénes? ] sostienen que los patrones de diseño no difieren significativamente de otras formas de abstracción [ cita requerida ] , y que el uso de nueva terminología (tomada prestada de la comunidad de arquitectura ) para describir fenómenos existentes en el campo de la programación es innecesario. El paradigma Modelo-Vista-Controlador se cita como un ejemplo de un "patrón" que es anterior al concepto de "patrones de diseño" por varios años. [2] Algunos [¿ quiénes? ] argumentan además que la principal contribución de la comunidad de patrones de diseño (y el libro Gang of Four ) fue el uso del lenguaje de patrones de Alexander como una forma de documentación; una práctica que a menudo se ignora en la literatura. [ cita requerida ]
¿Debería restaurarse algo de esto?-- Salix ( discusión ): 08:09 4 nov 2010 (UTC)
(de http://www.paulgraham.com/icad.html); quizás la discusión en http://www.c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatures también sea un buen comienzo. Dexen ( discusión ) 16:50 19 nov 2010 (UTC)Por ejemplo, en el mundo de la programación orientada a objetos se habla mucho de "patrones". Me pregunto si estos patrones no son a veces evidencia del caso (c), el compilador humano, en acción.
Referencias
El párrafo final de la sección de historia parece ser un anuncio de Patrones de diseño SOA . No estoy seguro de que este libro deba estar en esta página; ciertamente no merece su propio párrafo. EvanKroske ( discusión ) 01:49 19 nov 2010 (UTC)
Acabo de refactorizar la lista para eliminar las columnas gigantescas de bloques rojos que eran para libros que ni siquiera tienen una página wiki. Una era PoEAA y solo tenía dos patrones. La otra era PoSA2, que solo tenía patrones de concurrencia (y las primeras dos columnas no tenían patrones de concurrencia). Creo que lo que implementé es la mejor solución para esto, que es 1) separar los patrones de concurrencia en su propia tabla con la columna principal siendo PoSA2, y 2) agregar una columna "Otros", para enumerar las dos referencias a PoEAA así como cualquier otro libro que haga referencia a eso que pueda aparecer para los patrones que actualmente no tienen referencias. También cambié las celdas de la columna en blanco en la columna "Otros" a la plantilla n/a para darle una mejor apariencia general. Espero que estos cambios sean útiles. -- Renesis ( discusión ) 23:11, 17 de febrero de 2011 (UTC)
Blackboard no es un patrón de diseño sino una estrategia de comunicación. Sugiero eliminar esto —Comentario anterior sin firmar añadido por 80.148.12.242 (discusión) 09:28, 7 abril 2011 (UTC)
Enlace al sistema de componentes de entidad — Comentario anterior sin firmar añadido por 80.78.218.36 (discusión) 10:05, 16 de marzo de 2019 (UTC)
No entiendo esta crítica:
La idea puede no ser tan nueva como sugieren los autores: por ejemplo, el paradigma Modelo-Vista-Controlador es un ejemplo de un "patrón" que es anterior al concepto de "patrones de diseño" en varios años.
Hasta donde yo sé, ninguno de los autores afirma haber sido el primero en crear el concepto de patrones de diseño. Más bien, afirman ser los primeros en documentarlo explícitamente y crear un léxico para hablar de ellos. Una cita aquí sería muy útil. —Comentario firmado anterior añadido por 67.248.242.179 (discusión) 01:43, 20 de abril de 2011 (UTC)
Los patrones se descubren, no se inventan - Christopher Alexander (autor de "Un lenguaje de patrones" y creador de la idea de un lenguaje de patrones) — Comentario anterior sin firmar añadido por 92.40.253.45 (discusión) 21:35, 31 de octubre de 2011 (UTC)
Estoy aprendiendo este patrón de diseño y no sé nada sobre él, pero parece ser un estándar para manejar cosas en Flex (o algún cliente) que deben procesarse después de completar un proceso de servidor.
finalización de operaciones asincrónicas invocadas por el cliente."
Después de leer RAII, no parece un patrón de creación. ¿Podemos eliminarlo o moverlo de la sección de patrones de creación?
Si un patrón de diseño es una " solución general reutilizable para un problema que ocurre con frecuencia", ¿en qué se diferencia de un algoritmo? Este artículo no explica demasiado qué es exactamente un patrón de diseño. Un ejemplo sencillo sería un buen comienzo. WilliamSommerwerck ( discusión ) 19:13 7 sep 2011 (UTC)
Hace unos meses que me interesan los patrones de diseño de software. Una de las razones es por motivos educativos, creando una conferencia con Moodle . Hay muchos patrones de diseño, pero de alguna manera los que se definen en el libro de Patrones de Diseño se enseñan a menudo primero. Para ayudar a aquellos interesados en enseñar el tema (a sí mismos, ¿por qué no?) o que estén interesados en la historia de este tema, propongo agregar una categoría llamada Categoría:Patrón GoF o algo así para que los 23 patrones estén en una categoría. Como lugar predeterminado, agregaré el artículo del libro de Patrones de Diseño. ¿Cuál es tu opinión? Sae1962 ( discusión ) 15:57, 26 de julio de 2012 (UTC)
Los patrones de diseño y TRIZ son similares en el sentido de que ambos definen soluciones a problemas comunes. Una sección de "ver también" podría ser un camino secundario interesante. — Comentario anterior sin firmar agregado por Billegge ( discusión • contribuciones ) 12:23, 24 de octubre de 2012 (UTC)
borrar
redundante (pero con diferentes tipos), o simplemente no hay explicación de la diferencia? 68.183.23.147 ( discusión ) 23:38 16 ene 2013 (UTC)
No es que tenga nada en contra de estas referencias, pero ¿por qué debería importar la presencia o no de un patrón particular en estos libros? Hay numerosos patrones que se identificaron antes y después de estos que no están incluidos. Esta sección se lee como si fuera una religión, no como ingeniería de software. — Comentario anterior sin firmar agregado por 81.129.62.42 (discusión) 01:43, 15 de septiembre de 2013 (UTC)
Referencias
¿Debería figurar Proactor en la lista?
¿Tiene su propio artículo, pero no aparece aquí?
Parece que hemos creado una WP:LINKFARM . He movido todos los enlaces del artículo a la lista que aparece a continuación. ¿Alguien quiere revisar este lío y ver si hay algo que se ajuste a WP:EL lo suficientemente bien como para incluirlo? -- Ronz ( discusión ) 17:41 13 jun 2014 (UTC)
Referencias
El sitio web w3sDesign Patterns contiene material enciclopédico y preciso que resulta relevante para la comprensión del tema. Me gustaría añadir un enlace. ¿Qué opinan otros al respecto? Serv49 ( discusión ) 18:16 23 oct 2014 (UTC)
He añadido el enlace. Serv49 ( discusión ) 10:05 6 nov 2014 (UTC)
"Aunque los patrones de diseño se han aplicado en la práctica durante mucho tiempo, la formalización del concepto de patrones de diseño languideció durante varios años..."
¿Languidecido? ¿Por varios años? Creo que lo que se quiere decir aquí es que "Aunque los patrones de diseño se han aplicado prácticamente durante mucho tiempo, recién hace poco se formalizaron". GeneCallahan ( discusión ) 18:34 23 dic 2014 (UTC)
En varios patrones de diseño, los ejemplos de C# se han modificado para incluir el texto IVSR, p. ej., patrón Mediator . ¿Qué es IVSR? Cuando busco en Internet, no obtengo ningún resultado útil. ¿Podría ser que alguien esté intentando promocionarse a sí mismo ? Si es así, es necesario eliminarlo. De lo contrario, podría ser útil explicar qué es IVSR. — Comentario anterior sin firmar agregado por 46.44.173.1 (discusión) 12:02, 24 de febrero de 2015 (UTC)
La sección de Historia termina con la siguiente afirmación: "Aunque los patrones de diseño se han aplicado prácticamente durante mucho tiempo, la formalización del concepto de patrones de diseño languideció durante varios años". La referencia dada NO respalda la afirmación (hasta donde puedo ver en el .pdf de Baroni, et al .). Además, la afirmación es tan vaga que no tiene sentido. ¿Cuándo languideció? ¿Entre 1700 y 1900? ¿Entre 1987 y 1991? Tenga en cuenta que la página de inicio de Kent Beck (citada en Baroni) en http://c2.com/ppr/about/author/kent.html hace un par de afirmaciones que podrían verificar su afirmación de que habló sobre el uso de patrones de diseño formales para crear software. Pero ciertamente no está revisada por pares y, en mi humilde opinión, es una afirmación dudosa de primacía (ver más abajo); ¿es lo suficientemente autoritaria como para ser utilizada como un hecho? Me parece demasiado egoísta (sin ánimo de ofender). El problema principal que tengo es que, obviamente, los patrones se han utilizado en software al menos desde que se inventó el lenguaje de máquina (ya que un lenguaje ES un grupo de patrones). (y por supuesto, el hardware contiene en su núcleo un patrón repetido de circuitos...) Así que, a menos que haya una definición cuidadosa del término que lo distinga del lenguaje (y de una serie de otros métodos/procedimientos/lugares/abstracciones), no veo cómo se puede identificar el comienzo (¡seguramente algunas de las empresas de desarrollo de software utilizaron plantillas de diseño formal antes de 1987!) más allá de afirmar que el artículo de GoF de 1995 es el comienzo "reconocido", en general. Recomiendo que se elimine esa oración. No tiene ningún propósito real, por lo que yo sé. 216.96.76.54 (discusión) 13:11, 20 de julio de 2015 (UTC)
El usuario 216.96.76.54 tiene razón al postular que los patrones de diseño son más antiguos de lo que se menciona en la sección de historia de esta página. Edsger Dijkstra escribe sobre ellos en su artículo de 1972 'El humilde programador'. Cita: "Un subproducto de estas investigaciones puede tener una importancia práctica mucho mayor y, de hecho, es la base de mi cuarto argumento. El subproducto fue la identificación de una serie de patrones de abstracción que desempeñan un papel vital en todo el proceso de composición de programas". 85.76.82.209 (discusión) 07:31 9 ago 2019 (UTC)
Según la definición dada por el grupo HillSide, la definición dada (en la parte superior de la página wiki) de un patrón de diseño es incorrecta: http://hillside.net/patterns/50-patterns-library/patterns/222-design-pattern-definition
Cabe señalar que el grupo HillSide es el organismo rector de los patrones en el mundo del software. También cabe señalar que Richard (Dick) Peter Gabriel (también conocido como RPG) (director del grupo HillSide y también conocido por su lema "lo peor es mejor") ha analizado exhaustivamente el trabajo de Christopher Alexander (de donde surgieron los patrones), siendo un ejemplo el libro de RPG "Patterns of Software": http://dreamsongs.com/Books.html
Shkaboinka ( discusión ) 16:30 9 mar 2016 (UTC)
He añadido un enlace externo a GoF Design Patterns Open Online Learning (w3sdesign.com). ¿Estás de acuerdo? Serv49 ( discusión ) 18:21 20 oct 2016 (UTC)
Los patrones que implican un estado mutable pueden no ser adecuados para lenguajes de programación funcional, algunos patrones pueden resultar innecesarios en lenguajes que tienen soporte integrado para resolver el problema que intentan resolver y los patrones orientados a objetos no son necesariamente adecuados para lenguajes no orientados a objetos.
Me parece que, como frase única, es un poco pesada para el inicio. — MaxEnt 02:37, 4 de noviembre de 2016 (UTC)
Estaba revisando algunos patrones de diseño del libro Head First: Design Patterns y noté que las descripciones en esta página (en la sección de la lista de patrones) están tomadas directamente de allí, palabra por palabra. Lamentablemente, no puedo ocuparme de esto ahora, pero creo que debería solucionarse lo antes posible. — Ynhockey ( Discusión ) 15:15 26 ago 2017 (UTC)
La sección Tipos no tiene información relevante y es redundante (tiene un enlace roto (4)).
La sección Clasificación incluye toda la información relevante.
Véase también la sección anterior "tipos de patrones de diseño" vs. "clasificación".
La sección Tipos original:
Los patrones de diseño residen en el dominio de los módulos y las interconexiones. En un nivel superior hay patrones arquitectónicos que tienen un alcance mayor, y que normalmente describen un patrón general seguido de un sistema completo. [1]
Existen muchos tipos de patrones de diseño, por ejemplo [2] [3]
Vanderjoe ( discusión ) 16:02 6 sep 2017 (UTC)
Referencias
{{cite web}}
: La cita tiene un parámetro desconocido vacío: |dead-url=
( ayuda )Hola compañeros wikipedistas,
Acabo de modificar un enlace externo en Patrón de diseño de software . Tómese un momento para revisar mi edición . Si tiene alguna pregunta o necesita que el bot ignore los enlaces o la página en su totalidad, visite esta sencilla sección de preguntas frecuentes para obtener información adicional. Hice los siguientes cambios:
Cuando haya terminado de revisar mis cambios, puede seguir las instrucciones de la plantilla a continuación para solucionar cualquier problema con las URL.
Este mensaje fue publicado antes de febrero de 2018. Después de febrero de 2018 , las secciones de la página de discusión "Enlaces externos modificados" ya no son generadas ni monitoreadas por InternetArchiveBot . No se requiere ninguna acción especial con respecto a estos avisos de la página de discusión, aparte de la verificación regular utilizando las instrucciones de la herramienta de archivo que se encuentran a continuación. Los editores tienen permiso para eliminar estas secciones de la página de discusión "Enlaces externos modificados" si desean despejar las páginas de discusión, pero consulte la RfC antes de realizar eliminaciones sistemáticas masivas. Este mensaje se actualiza dinámicamente a través de la plantilla (última actualización: 5 de junio de 2024) .{{source check}}
Saludos.— InternetArchiveBot ( Reportar error ) 07:33, 7 de diciembre de 2017 (UTC)
Siento que este artículo adolece de falta de definición.
El título sugiere que los patrones de diseño son una noción general en el desarrollo de software. Solo los he visto como una práctica específica del software orientado a objetos, introducida por el libro de Gamma et al. Algunos patrones de diseño, como MVC, existían antes del libro, pero nunca he visto que la idea se aplicara a otros tipos de software. Si se ha hecho, y si el término patrón de diseño se aplica realmente en esos casos, sin duda son la excepción.
En el desarrollo de software, tenemos todo tipo de patrones de diseño establecidos que no están vinculados a la orientación a objetos, como la arquitectura cliente-servidor, la arquitectura multicapa, la arquitectura de flujo de datos y pipelines, el paso de mensajes, la programación concurrente con memoria compartida y primitivas IPC, los subprocesos de software, las interrupciones de software, etc., etc., pero ninguno de ellos se conoce realmente con el nombre de patrón de diseño, hasta donde yo sé. El presente artículo define el término como si tales cosas estuvieran incluidas y luego pasa a analizar exclusivamente el concepto específico introducido por Gamma et al. Esto es confuso e inconsistente.
O bien el artículo debería limitarse a discutir los patrones de diseño tal como se conocen en el desarrollo de software orientado a objetos, y el título y el párrafo introductorio deberían modificarse para reflejar eso; o al menos debería comenzar discutiéndolos, antes de continuar discutiendo cómo se aplican los patrones de diseño en el software no orientado a objetos (cuya existencia el texto actual ni siquiera menciona).
¿Estás de acuerdo? ¿Qué enfoque preferirías? Rp ( discusión ) 14:11 11 nov 2022 (UTC)
Acabo de aclarar algunos datos sobre Christopher Alexander al comienzo de la sección de Historia.
También he añadido una referencia a su discurso de apertura en la Convención OOPSLA de 1996. Esto proporciona más detalles sobre la historia de un lenguaje de patrones en arquitectura y cómo ha evolucionado más recientemente. En particular, Christopher Alexander sugirió importantes oportunidades de colaboración entre el diseño de software y el trabajo del lenguaje de patrones arquitectónicos que él había ayudado a desarrollar. CuriousMarkE ( discusión ) 23:35, 24 de agosto de 2024 (UTC)