Mediante determinadas reglas que se definen como patrones se puede desarrollar aplicaciones sin tener demasiados conocimientos del campo en que se deba utilizar la aplicacion.
Tambien son interesantes los anti-patrones.
Por supuesto, esto siempre sirve para areas o rubros en los que no se tiene experiencia, ya que la experiencia siempre aporta mucho mas que reglas teoricas.

A mi, la definición de Patrón de Diseño que me parece más clarificadora es esta: “Un patrón de diseño es una solución probada a un problema”. Es decir, es una solución que funciona… aunque no siempre es la mejor.

Y patrón de diseño más divertido que conozco es el patrón “Sacrifica a una persona”, el cual propone como solución a los proyectos de software que mal-terminan sin documentación el hecho de “sacrificar a un programador para que genere la documentación y exista así una documentación mínima”. En esto de los patrones hay de todo ;-p.

Para patrones, estos: http://bgmaker.ventdaval.com/

No he entendido nada…. ¿Cuando os referiis a Patrones quereis decir “Guiones de estructura web”? osea ¿Un dibujo de como tiene que circular la informacion en la web?

En mi opinion el problema de buscar mucho los patrones de diseño es que uno pierde la posibilidad de encontrar un patron nuevo

Por ejemplo:

Soy Zoper y en estos momentos esta construyendo la version 3 que no es mas que la 2 implementada via patrones de diseño

Bien, buena idea pero se me ocurren formas mucho mas interesantes de construir informacion que un Modelo Vista Controlador o cosas como estas

Por ejemplo: Ruby on Rails vs. Zope

Ruby on Rails explota el patron MVC que esta bien, pero me llama mucho mas la atencion resolver la situacion de un modo un poco mas facil

De todos modos comparto la importancia en la teoria (y en una buena parte de la practica) de los patrones puesto que una nueva tecnica de hoy es un patron mañana

Saludos

Aquí explica lo que son los patrones de diseño.

http://www.1×4x9.info/files/patrones/html/online-chunked/

Saludos

Donde hay patrón no manda marinero. (Lo siento, no he podido contenerme).

Patrones de diseño y la programacion artistica

No soy un analista, si acaso mas bien un analista/programador. ¿Diferencias? El tamaño de los sistemas de informacion a los que me puedo enfrentar (aunque el arquitecto creo que no es un analista, estas cosas se suelen confundir)….

Bueno, yo ahora mismo estoy haciendo una asignatura que se llama Ingenieria del Software II en la que precisamente se basa en patrones de diseño para programación. La verdad, faicilitan mucho la tarea cuando alguien se prepara a hacer un diseño. Tienes un problema, bien, no lo pienses, ya hay un patrón que hace lo que quieres y de manera eficiente. Sólo hay que saber aplicarlo.

encontrar patrones es lo más difícil que ha parido madre, hace falta un olfato especial para ello, alcanzar el grado de maestro iniciado. El GOF, O’Coplien, Meyers y los del grupo POSA , de ahí podeis sacar unas herramientas cojonudas para aplicar al diseño de todo típo de problema. EN teoría un buen design pattern es aquel que resuelve un problema permitiendo que la implementación final en capas mantenga independencia y ortogonalidad, lo que significa que pueda cambiar o extender una parta de la aplicación multicapa sin cambiar el resto. Hay muy buenos ejemplos para procesamiento distribuidos en red en el libro del POSA2 y escrito como no en C++ y algo en JAVA, os invito a sumergiros en su lectura y cambiar la conciencia del simple picador de código alienado.

Se podría decir, que en esto de la programación, y con mas detalle, la programación orientado a objetos la madre del cordero son los patrones de diseño, como soluciones probadas, son mas fiables que las soluciones que tu puedas llegar a generar en algún momento, ya que un patrón de diseño surge de la colectividad y como solución a un problema común estratégico dentro del desarrollo del software (dificilmente algo que es producto de un conjunto de analistas del software, y supervisado por un conjunto de analistas del software pueda ser superado por un único analista, a no ser que hablemos de genios). Como el desarrollo del software cubre todos los lenguajes de programación, los patrones de diseño son aplicables a cualquier implementación del paradigma orientado a objetos (ya que la programación estructurada no es capaz de la reutilización mas alla de un copy&paste o una estructura de tuberias). En uno de los comentarios se lee que no es normal encontrar un proyecto o problemas en el que el paradigma orientado a objetos sea utilizable para resorverlo. Yo mas bien lo expresaria al contrario, es dificil no encontrar un proyecto en el que no sea aplicable el paradigma orientado a objetos (aunque no imposible hay algunos casos extremos en los que no es aplicable) y dentro de ellos es imposible no encontrar problemas comunes que han sido resueltos previamente por otros desarrolladores. Los patrones de diseño, en definitiva, fue una evolución normal dentro de la POO cuando llego al punto de madurez suficiente como para ser considerada como ingenieria del software. Los antipatrones son aquellas soluciones propuestas y que hay consenso en que no son lo eficientes que deberían. Al final en esto de los patrones de diseño, se ha llegado al punto que cualquier hijo de vecino quiere tener el suyo propio, se crean muchos todos los días y se califican como antipatrones muchos otros de una forma arbitraria. Quizás producto de la poca cultura que hay aún de ingenieria en el área del desarrollo del software y de la gran cultura del guruismo que impera a nivel internacional. Al final, lo que vale es basarse en catálogos de patrones que por los años de vigencia, ratifiquen su condición de consensuados dentro de un colectivo grande de desarrolladores, y dejar que los nuevos patrones con nombre propio tengán su largo periodo de maduración que los convierta realmente en la tan ansiada categoría. Los patrones de diseño no son mas que una herramienta mas, que nos permiten llegar al fin de desarrollar software de calidad que cumpla los requerimientos del paradigma orientado a objetos (CONSTRUCCION DE SOFTWARE ORIENTADO A OBJETOS, Bertrand Meyer, ISBN: 8483220407). Disculpad y corregid los errores que haya podido cometer en mi intervención.

En agosto, Yusef Hassan empezó a escribir tres artículos sobre patrones de Diseño de interacción, en la bitácora G4 de sidar:
Patrones de Diseño de Interacción (I): Introducción
Patrones de Diseño de Interacción (II): Estructura y CaracterísticasPatrones de Diseño de Interacción (III): Colecciones y Lenguajes de Patrones
Seguro que a más de uno nos viene bien recordarlo.
Saludos.

Hay que admitir que este blog a veces se sale.

Hay una cierta confusión entre técnicas y patrones de diseño, las técnicas de programación serían el paso posterior al patrón de diseño, hay un buen ejemplo de esto por ejemplo con el patrón singleton donde se garantiza la construcción de un solo objeto de cada clase, al mismo tiempo convendría que la implementación del constructor fuera virtual, por qué? supongamos queremos crear el objeto singleton durante el tiempo de ejecución y que no sabemos el tipo hasta ese momento, utilizamos entonces el constructor virtual como técnica para la creación del singleton. Los contadores de referencia son otra técnica más fácilmente confundible con un patrón, la técnica se diferencia de un patrón en que la técnica es más especifica, resuelve problemas de implementación pero no de diseño y por tanto es más dependiente de un lenguaje de programación completo, en el caso del constructor virtual claramente de una implementación en c++.

un saludo

para resumir.

Patrón de diseño: diseño de interfaces y la comunicación entre objetos-interface

Técnica de programación: patrón de diseño para implementación de interfaces.

de nuevo un saludo

[...] Como nos contaba Minid hace unos meses, los patrones son una excelente herramienta, sobre todo, para no tener que reinventar la rueda una y otra vez. Todo buen ingeniero que se precie se ha pegado alguna vez, como mínimo en la universidad, con los patrones de diseño. A veces incluso los hemos usado sin ser conscientes de ello. [...]