stringtranslate.com

Discusión:Patrón de diseño de software

El titulo

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óncontribuciones ) 18:16, 12 de diciembre de 2010 (UTC) [ responder ]

Hacer de la lista su propia página

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) [ responder ]

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

Ejemplos extraños

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) [ responder ]

Estoy de acuerdo contigo. Siéntete libre de eliminar los ejemplos que no aporten nada a la explicación del patrón. -- Antonielly ( discusión ) 13:53 8 abr 2009 (UTC) [ responder ]
Saluda al mundo — Comentario anterior sin firmar añadido por 61.4.76.7 (discusión) 03:37 29 oct 2014 (UTC)[ responder ]
Me atreví a vincular todas las ediciones a esta discusión. Estoy seguro de que enojé a algunas personas, pero esto realmente tenía que hacerse. Dejé un ejemplo como PHP5 porque era el único ejemplo conciso. Borré horas y horas de trabajo. Nuevamente, si la gente quiere recuperarlo, Wikibooks probablemente sea un buen lugar para ello. Wikipedia debería ser la punta del iceberg y no debería detenerse en detalles específicos de los idiomas en estos temas a menos que los detalles sean muy relevantes para los patrones. Todavía hay algunas páginas con largas listas de enlaces a implementaciones en varios idiomas. —Ben FrantzDale ( discusión ) 00:11, 9 de abril de 2009 (UTC) [ responder ]
También estoy de acuerdo, tantos ejemplos de código no aportan nada. Además, esto es coherente con la política de Wikipedia de no seguir un manual de instrucciones . -- Enric Naval ( discusión ) 03:45 9 abr 2009 (UTC) [ responder ]

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) [ responder ]

Sería 61.115.196.46, cuya reversión lleva el comentario " Hubo un idiota que eliminó los ejemplos para todos los lenguajes excepto Java. Yo dependía de esto para crear singleton para mis proyectos y sólo para encontrarme con que fueron eliminados por un idiota ". Pero eso no cambia el hecho de que Wikipedia no es un libro de texto de programación. El propósito de estos artículos debería ser explicar qué son los patrones de diseño en general y explicar los patrones específicos en términos generales, no proporcionar bibliotecas de código fuente para su uso mediante cortar y pegar. He deshecho su reversión. RossPatterson ( discusión ) 11:31, 13 de abril de 2009 (UTC) [ responder ]
En serio. Si alguien dependiera de los ejemplos para su proyecto, seguramente habría entendido la versión de Java y la habría aplicado en el lenguaje de su elección. A menos que 61.115.196.46 sea simplemente copiar y pegar de Wikipedia en lugar de programar ;-) —Ben FrantzDale ( discusión ) 11:35, 13 de abril de 2009 (UTC) [ responder ]
¡Atrévete y muévelos a Wikilibros! Si lo haces, agrega enlaces a ellos aquí. —Ben FrantzDale ( discusión ) 11:35 13 abr 2009 (UTC) [ responder ]
Si querías ser lo suficientemente valiente como para borrar todos los ejemplos, también deberías haberlos movido a los libros wiki. Entiendo tu motivación, pero no deberías hacer el trabajo destructivo sin hacer a su vez el trabajo constructivo. — Comentario anterior sin firmar añadido por 192.35.35.34 ( discusión ) 23:59, 12 de agosto de 2011 (UTC)[ responder ]
Soy el usuario 201.253.239.87 ahora (IP dinámica), he deshecho la revisión del patrón de visitante de BenFrantzDale (Razón: "Uno no es suficiente para mí (pero ejemplos más cortos/minimalistas sí lo serían)" en respuesta a "Ejemplos de C++ y D eliminados. Uno es suficiente" de BenFrantzDale y más tarde encontré esta discusión. Creo que los ejemplos implementados en un lenguaje son buenos para aprender, tanto el lenguaje (muestra características sobre él) como el patrón. Creo que los ejemplos deberían haberse movido a otro lugar (por ejemplo, wikilibros) y se debería haber vinculado a ellos antes de eliminarlos. —Comentario anterior sin fecha agregado a las 05:28, 15 de abril de 2009 (UTC).
Estoy de acuerdo en que Wikibooks es probablemente el mejor lugar para esto. Conociendo el patrón bastante bien, no puedo ver ninguna diferencia entre los ejemplos, cada uno tiene interfaces/estructuras CarElementVisitor y CarElement y algunas clases que las implementan. El resto es solo equipaje que oscurece el patrón. Ahora he copiado los ejemplos a Wikibooks en [1]. -- Salix ( discusión ): 09:05, 15 de abril de 2009 (UTC) [ responder ]
¡Genial, gracias! Parece que eso debería mantener a todos contentos y evitar que se desperdicie el trabajo duro de la gente. —Ben FrantzDale ( discusión ) 13:21 15 abr 2009 (UTC) [ responder ]

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) [ responder ]

Sí, yo diría que sí. Me parece bastante bueno. RossPatterson ( discusión ) 22:38 15 abr 2009 (UTC) [ responder ]
Se ve bien. Acabo de reformular el enlace para que diga "Implementaciones de visitantes en varios idiomas", lo que a mí me parece más legible. Comencé a hacer lo mismo con Singleton, moviendo todos los ejemplos que borré antes. ¡Excelente progreso! —Ben FrantzDale ( discusión ) 00:47, 16 de abril de 2009 (UTC) [ responder ]
¿Puede alguna mente sabia añadir críticas bien documentadas? —Comentario anterior sin firmar añadido por 192.193.221.141 ( discusión ) 14:59, 29 de abril de 2009 (UTC)[ responder ]
Añadiendo un enlace a wikilibros en la página de patrones de Observer —Comentario anterior sin firmar añadido por Ariadie ( discusióncontribs ) 08:49, 12 de mayo de 2009 (UTC)[ responder ]

Recién agregado POSA2

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) [ responder ]

Hecho 123.224.241.172 (discusión) 14:48 25 abr 2009 (UTC) [ responder ]
Hmm, sería mejor tener solo POSA y luego escribir, por ejemplo, "1" o "2" o "no" en la columna. Acabo de agregar MVC y, según la búsqueda de libros de Amazon, MVC está en POSA1. Stachelfisch (discusión) 20:46 3 jul 2009 (UTC) [ responder ]

Categoría de patrón fundamental

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 urnbulldiscusión 03:59, 4 de junio de 2009 (UTC) [ responder ]   

Si no hay objeciones, colocaré la plantilla del neologismo :
Por la razón antes citada. Además, si no se resuelve su contradicción con el patrón fundamental, creo que está justificado añadir contradict-other:
 dm yers t urnbull  discusión 06:58 10 jul 2009 (UTC) [ responder ]

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.

jklowden discusión mar., 14 jul. 2009 21:36:24 EDT —Comentario anterior sin fecha añadido a las 01:37, 15 de julio de 2009 (UTC).[ responder ]
Existen fuentes que definen conceptos similares. Véase el capítulo 2.3.1 de Meta-Compilation for C++ [2], que también proporciona más referencias. Creo que dmyersturnbull tiene muchos puntos excelentes que vale la pena investigar. A medida que más personas estudian un concepto, se llega a una comprensión más profunda. El hecho de que una obra seminal se refiera a algo no significa que un campo no pueda avanzar más allá de eso. De lo contrario, el argumento sería mudo, ya que todos programaríamos en MIX . Bpringlemeir ( discusión ) 01:41, 16 de julio de 2010 (UTC) [ responder ]
Err, supongo que no estoy de acuerdo con dmyersturnbull (y aparentemente no sé leer). De todos modos, vale la pena echarle un vistazo a la referencia anterior si estás interesado en esto. Hay literatura en la que la gente intenta diseccionar la naturaleza universal de un patrón. Al igual que con el ejemplo de varios idiomas anterior, un exceso de cosas llamadas patrones también puede diluirse. Bpringlemeir ( discusión ) 01:48, 16 de julio de 2010 (UTC) [ responder ]
"La encapsulación y la herencia son instrucciones generales para estructurar el código..." En otras palabras, ¿patrones? ¡Esto parece la definición misma de un patrón! GeneCallahan ( discusión ) — Comentario anterior sin fecha agregado a las 18:15, 23 de diciembre de 2014 (UTC)[ responder ]

¿Por qué Factory no aparece en la lista?

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) [ responder ]

Una fábrica simple suele considerarse diferente de un método de fábrica, ¿no? Teniendo en cuenta que es tan importante, parece razonable enumerar las tres, o simplemente enumerar la fábrica y tener los subtipos enumerados en su página wiki respectiva. 82.26.250.60 (discusión) 22:26, ​​6 de septiembre de 2023 (UTC) [ responder ]
(Resuelto, el método de fábrica ahora está incluido)

¿Debería Multiton cotizar en bolsa?

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) [ responder ]

Patrones de integración empresarial

¡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

Azbarceadiscusión vie 11 jun 09:55:24 UTC 2010 —Comentario anterior sin fecha añadido 08:56, 11 jun 2010 (UTC).[ responder ]

Sección de crítica

Un anónimo eliminó la sección de críticas [3] con el comentario

(Se trasladó información válida de una sección de críticas al resto del artículo. En el proceso, se eliminó información que era resultado de la ignorancia personal del escritor).

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) [ responder ]

Yo diría que sigan adelante y vuelvan a incluir esta sección. Tal vez no sea la mejor fuente en este momento, pero hay críticas publicadas por ahí; esperemos que se agreguen más enlaces lo suficientemente pronto. Una cosa me viene a la mente: Paul Graham

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.

(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) [ responder ]
Tal como está ahora, la sección de crítica se basa en la ignorancia; critica el "concepto" de patrones. Eso es como criticar el "concepto" de soluciones o respuestas a preguntas o fórmulas. (Software/Diseño/Arquitectura) Los patrones son documentación de soluciones de una manera relativamente consistente. Los patrones individuales pueden ser "deficientes" o "incorrectos", pero eso los convierte en antipatrones o soluciones deficientes; no hace que el concepto de patrones sea incorrecto, en todo caso, los justifica aún más. MartinSpamer ( discusión ) 07:22 27 nov 2011 (UTC) [ responder ]
Tu frase parece ajustarse a la crítica de que los "patrones de diseño" no son nada nuevo. "Eso es como criticar el 'concepto' de soluciones o respuestas a preguntas o fórmulas". ¿Qué no es una solución o una respuesta? Los ingenieros (de software), tal como yo los entiendo, aplican el conocimiento para resolver problemas. De ello se desprende que siempre ha habido "patrones de diseño" desde que existen los ingenieros (de software), y por lo tanto los "patrones de diseño" existían mucho antes de la Banda de los Cuatro. Pero tal vez te refieras a algo más específico que solo el conocimiento. Pero, de nuevo, tal vez no. Una solución, buena o mala, aborda algún problema. La documentación registra esta solución en una forma que puede transmitirse a otra persona. Una "forma relativamente consistente" podría significar, en extremo, totalmente consistente, como algunos tipos de lógica, o algo totalmente libre, como algunos tipos de arte (y sí, la gente se ha inspirado para crear y documentar una solución basada en un encuentro con el arte). Si estos son "Patrones (de software/diseño/arquitectura)", entonces afirmo, en primer lugar, que tienes razón en que "no hace que el concepto de patrones sea erróneo", porque ¿cómo puede ser erróneo un concepto?, y en segundo lugar, que una parte de la sección de crítica es realmente válida porque el concepto /de un concepto/ no es nada nuevo (aunque, para darle un giro, nuestro /concepto/ de un concepto ha cambiado con el tiempo). En otras palabras, el concepto de "patrón de diseño" me parece indistinguible del "conocimiento", y por lo tanto podría enunciarse como: el conocimiento es la documentación de soluciones de una manera relativamente consistente, y prácticamente decir lo mismo. Es bastante revelador que pongas todos los adjetivos de "patrones" entre paréntesis, lo que sugiere que no te refieres solo a los patrones de diseño de software, sino a los patrones en general.
(George Paci, por cierto, afirmó lo mismo sobre otra de las ideas de Christopher Alexander, que "QWAN" era un reemplazo de "bueno" (... '"Ese diseño es bueno" y los reescribe como "Ese diseño tiene QWAN"'). Lo mismo aquí, donde "patrón de diseño" reemplaza a "patrón" (o "concepto")).
Para que no me acusen de algo que no dije, quiero dejar claro que yo también apoyo el concepto de documentar las soluciones de una manera relativamente consistente (y por lo tanto estoy en contra de la "inconsistencia", es decir, algo así como "indisciplinado", o "que ignora el conocimiento previo (respecto de los patrones) sin razón"). Sin embargo, no creo que toda esta charla sobre patrones de diseño haya aportado mucho, y tal vez nada en absoluto, en comparación con lo que habríamos hecho si no hubiéramos tomado prestadas las ideas de Alexander. Si él fue el primer arquitecto en documentar soluciones (repetidas), bien por él. Si la Banda de los Cuatro fue la primera en documentar el conocimiento de los ingenieros (de software), bien por ellos. Sin embargo, no creo que ese pueda ser el caso. Eso no quiere decir que nuestras formas de registrar el conocimiento nunca hayan cambiado: sí lo han hecho. Más bien, los patrones (de diseño) podrían considerarse (y definirse como un paso hacia un buen /concepto/) como documentación de soluciones de una manera /más/ consistente, más consistente que todo lo que vino antes. Desde este punto de vista, un "patrón de diseño" en realidad parece simplemente una forma de conocimiento organizado, en lugar de estar disperso en un millón de cerebros y bases de datos, de forma similar a como Wikipedia es una forma de conocimiento organizado en comparación con los millones de fuentes que (supuestamente) cita.
En definitiva, yo dejaría de hablar de patrones de diseño porque ya hay campos en expansión que hablan del conocimiento. Por ejemplo, los científicos cognitivos hablarían de "representaciones mentales" y podrían plantear preguntas que los expertos en patrones de diseño no podrían plantearse, como por ejemplo si algunas representaciones mentales son más "difíciles" que otras, por ejemplo, si requieren más tiempo de procesamiento. Esto podría tener relevancia para la ingeniería de software porque podría decirnos, de alguna manera, si algunos "patrones de diseño" nos dan más problemas que otros. En otras palabras, los patrones de diseño de software (la Banda de los Cuatro, las ideas de Alexander, etc.) me parecen desconectados del resto de nuestro conocimiento. Esto es malo. En todo caso, los justifica menos.
tl;dr: los patrones de diseño de software se han vuelto indistinguibles del conocimiento o los conceptos, y se puede prescindir de todo lo que se dice sobre ellos, pero no de aquello a lo que se refieren. KaiSeun ( discusión ) 07:25 16 feb 2012 (UTC) [ responder ]

Referencias

  1. ^ Peter Norvig , en Design Patterns in Dynamic Programming , analiza la trivialidad de implementar varios patrones en lenguajes dinámicos . Norvig, Peter (1998-03-17). "Design Patterns in Dynamic Programming" . Consultado el 29 de diciembre de 2007 .Norvig y otros han descrito características del lenguaje que encapsulan o reemplazan varios patrones que un usuario de C++ debe implementar por sí mismo.
  2. ^ Reenskaug, Trygve . "MVC XEROX PARC 1978-79" . Consultado el 9 de junio de 2008 .

El párrafo suena como un anuncio

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) [ responder ]

Nueva apariencia de la lista

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) [ responder ]

Lista de patrones

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) [ responder ]

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) [ responder ]

Crítica - Novedad

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) [ responder ]

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) [ responder ]

¿Qué pasa con el token de finalización asincrónica (ACT)?

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.

"El patrón de diseño de token de finalización asincrónica distribuye de manera eficiente acciones de procesamiento dentro de un cliente en respuesta a la

finalización de operaciones asincrónicas invocadas por el cliente."

¿Por qué se incluye RAII en el patrón de diseño?

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?

Apoyo la eliminación. RAII es más exactamente un lenguaje de programación , no un patrón de diseño. -- Demonkoryu ( discusión ) 09:53 8 ago 2011 (UTC) [ responder ]
Apoyar la eliminación. Un modismo de programación es algo menos versátil que un patrón de diseño de software. -- Sae1962 ( discusión ) 08:58 29 nov 2016 (UTC) [ responder ]

patrones de diseñocontraalgoritmos

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) [ responder ]

Como respuesta rápida, diría que los patrones de diseño se diferencian de los algoritmos en que los patrones de diseño resuelven problemas de ingeniería de software en lugar de problemas de informática. Es decir, son plantillas para gestionar la complejidad que surge de la interacción entre los componentes del software. Hay muchas formas de implementar la búsqueda en profundidad , por lo que, aunque el algoritmo puede ser el mismo, su implementación puede ser mucho más preferible desde una perspectiva de diseño de software en términos de reutilización del software, etc. De todos modos, esa es una idea general de una respuesta. 20:38, 7 de septiembre de 2011 (UTC)
Si buscamos algoritmos , se los describe como "una lista finita de instrucciones bien definidas", y yo diría que es bastante diferente. Desafortunadamente, los patrones de diseño son un tema avanzado y, en parte, por eso es tan difícil explicarlos. Normalmente, se pueden utilizar uno o más patrones de diseño en una solución de algoritmo expresada en un lenguaje informático particular. Se han escrito libros sobre el tema.
Al igual que en las películas clásicas de artes marciales chinas, se necesita un buen kung fu (término) , no sólo conocimientos básicos de cómo mover los brazos y las piernas. – rfrankla ( discusión ) 10:42, 21 de abril de 2014 (UTC) [ responder ]

Creando una nueva categoría

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) [ responder ]

En general, apoyo. Sin embargo, yo cambiaría el nombre a Categoría:Patrones de diseño de la Banda de los Cuatro. El nombre de esta categoría debería estar en plural y, por lo general, escribir las cosas con todas sus letras resulta más claro para los lectores ingenuos.
Tenga en cuenta también que si utiliza los dos puntos iniciales, podrá vincular a categorías sin necesidad de utilizar el marcado <nowiki> . Andy Dingley ( discusión ) 16:08 26 jul 2012 (UTC) [ responder ]

Véase también la sección

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óncontribuciones ) 12:23, 24 de octubre de 2012 (UTC) [ responder ]

borrar

borrar

"Tipos de patrones de diseño" vs "Clasificación"

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) [ responder ]

Nadie lo ha solucionado después de más de un año. ¿Alguna objeción razonable a la eliminación de los "tipos"?

En Patrones de Diseño/Código Completo - WTF

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) [ responder ]

Antes de la publicación de GOF se sabía poco sobre el tema. Los autores querían proporcionar un vocabulario estándar para que los profesionales pudieran comunicar sus pensamientos e ideas. Para comenzar el proceso, eligieron deliberadamente "algunos de los patrones de diseño más importantes y los presentaron como un catálogo". [1] (Estoy siendo informal porque esta es la página de discusión). En virtud de la cantidad de copias vendidas y la aceptación de estas ideas por parte de los ingenieros de software, estos libros son las referencias reconocidas sobre el tema. – rfrankla ( discusión ) 09:34, 21 de abril de 2014 (UTC) [ responder ]
Estoy de acuerdo: el hecho de que un patrón aparezca en un libro u otro es completamente irrelevante. Es como hacer una lista de aves que se encuentran en una guía de campo en particular. — Comentario anterior sin firmar añadido por 68.183.37.167 ( discusión ) 14:32, 28 de mayo de 2014 (UTC)[ responder ]

Referencias

  1. ^ Página 2 del GOF

Proactor

¿Debería figurar Proactor en la lista?

Patrón de delegación

¿Tiene su propio artículo, pero no aparece aquí?

Los enlaces externos se movieron a la conversación

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) [ responder ]

Referencias

Enlace externo a w3sdesign.com

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) [ responder ]

He añadido el enlace. Serv49 ( discusión ) 10:05 6 nov 2014 (UTC) [ responder ]

¿Languidecer?

"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) [ responder ]

Incluso en 2014, cuando se escribió el comentario original aquí, esto no era cierto; la formalización de los "patrones de diseño" es anterior a los libros por algunos años. Simplemente no se los llamaba "patrones de diseño". — Comentario anterior sin firmar agregado por 171.20.64.8 (discusión) 12:33, 16 de noviembre de 2023 (UTC)[ responder ]

IVSR

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) [ responder ]

Historia

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) [ responder ]

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) [ responder ]

Definición

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) [ responder ]

Enlace externo adicional

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) [ responder ]

Niebla pesada

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) [ responder ]

Copiar y pegar / plagio

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) [ responder ]

Este artículo se inició en 2003 y estaba bien desarrollado en 2009, cuando se publicó el libro. Es posible que el libro haya copiado Wikipedia. ~ Kvng ( discusión ) 00:04 22 sep 2018 (UTC) [ responder ]
En realidad, el libro se publicó por primera vez en 2004, pero sospecho que el libro cita directamente el libro original de GoF o de otras fuentes más autorizadas. Hice una comparación entre las 23 descripciones de patrones de diseño en el libro de GoF y las descripciones en la tabla del artículo, y hay muchas coincidencias cercanas. (Todavía no miré ninguna otra fuente). Sin embargo, no estoy seguro de cuánto margen de maniobra hay con respecto a la paráfrasis cercana en este contexto, ya que las definiciones de GoF son bastante breves. Ahiijny ( discusión ) 19:55, 13 de octubre de 2018 (UTC) [ responder ]
Mis impresiones subjetivas:
  • 0 = coincidencia exacta
  • 0,1 = coincidencia muy cercana
  • 0,5 = algo diferente
  • 1 = bastante diferente
Ahiijny ( discusión ) 19:55 13 oct 2018 (UTC) [ responder ]

Se movió la sección Tipos a la página Discusión.

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]

Patrones de estrategia de algoritmos
Abordar las inquietudes relacionadas con las estrategias de alto nivel que describen cómo explotar las características de las aplicaciones en una plataforma informática. [ aclaración necesaria ]
Patrones de diseño computacional
Abordar las preocupaciones relacionadas con la identificación de cálculos clave. [4] [5]
Patrones de ejecución
Que abordan cuestiones relacionadas con el soporte de nivel inferior de la ejecución de aplicaciones, incluidas estrategias para ejecutar flujos de tareas y para la definición de bloques de construcción para soportar la sincronización de tareas.
Patrones de estrategia de implementación
Abordar las inquietudes relacionadas con la implementación del código fuente para respaldar
  1. organización del programa, y
  2. las estructuras de datos comunes específicas de la programación paralela.
Patrones de diseño estructural
Abordar las inquietudes relacionadas con las estructuras globales de las aplicaciones que se están desarrollando.


Vanderjoe ( discusión ) 16:02 6 sep 2017 (UTC) [ responder ]

Referencias

  1. ^ Martin, Robert C. (2000). "Principios de diseño y patrones de diseño" (PDF) .
  2. ^ https://sourcemaking.com/design_patterns
  3. ^ "Patrones de diseño | Diseño orientado a objetos". www.oodesign.com . Consultado el 8 de abril de 2017 . {{cite web}}: La cita tiene un parámetro desconocido vacío: |dead-url=( ayuda )
  4. ^ "Categoría: Patrones de pensamiento computacional – Wiki de diseño de juegos escalables". sgd.cs.colorado.edu . Consultado el 26 de diciembre de 2015 .
  5. ^ "Introducción a la ingeniería de software, arquitectura y patrones de diseño – Wikilibros, libros abiertos para un mundo abierto". en.wikibooks.org . Consultado el 26 de diciembre de 2015 .

Enlaces externos modificados

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) [ responder ]

Título y alcance

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) [ responder ]

Información histórica adicional

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) [ responder ]