design - lista - patrones de diseño web
¿Cómo sabes cuándo usar patrones de diseño? (14)
¿Cómo aprendiste cuándo usar una instrucción if?
Lo comparo con eso porque es una construcción más grande que necesita conocer los pormenores antes de que pueda usarla efectivamente. Una instrucción if resuelve una clase de problemas que necesitan ramificación. Un patrón de puente resuelve una clase de problemas. Realmente no los veo de manera diferente.
Cualquiera puede leer el libro de GoF para conocer los patrones de diseño y cómo usarlos, pero ¿cuál es el proceso para descubrir cuándo un patrón de diseño resuelve un problema? ¿Impulsa el diseño del diseño del patrón o existe una forma de descubrir cómo se puede usar un patrón para cambiar un diseño?
En otras palabras, ¿hay patrones para Patrones?
¿Patrones de diseño? ¡Estás empapando en ellos!
No hay nada especial en los patrones de diseño, simplemente son patrones de diseño. Todo desarrollo usa patrones de diseño. Hay un cierto conjunto de patrones de diseño en la programación orientada a objetos que se consideran generalmente deseables y se han convertido en los patrones de diseño canónicos. Pero también hay muchos patrones de diseño indeseables o indiferentes (como antipatrones de diseño ), así como patrones no descubiertos y / o no documentados.
No puede evitar el uso de patrones al programar. Pero puede ser más consciente de los patrones que está utilizando y de cuándo ciertos patrones son útiles y cuándo no. Estudiar los patrones de diseño canónicos del libro de GoF ayudará, al igual que aprender sobre el código de olores y refactorización . No hay una respuesta correcta para cuando se debe usar un patrón de diseño o diseño en particular, necesita acumular experiencia en su uso e implementación para saber cuándo y dónde usar qué patrón.
El concepto de un patrón de diseño se ha tomado de la ingeniería estructural, como ocurre con muchas prácticas en ingeniería de software. Si considera construir una estructura, hay decisiones que deben tomarse sobre cómo construir esa estructura para lograr los objetivos establecidos. Al tomar esas decisiones, tendrá un conjunto de requisitos para trabajar. Puede ser algo tan simple como que Bridge debe ser capaz de soportar X toneladas a la vez, o tener una resistencia a la tracción particular para permitir suficiente movimiento en el viento, etc. Un arquitecto usaría conocimiento previo de otras construcciones para tomar esas decisiones de diseño. Es muy poco probable que trate de resolver el problema desde cero.
La Ingeniería del Software y los Patrones de Diseño son exactamente lo mismo. Son simplemente soluciones comunes a problemas comunes. Si conoce los patrones de diseño, cuando está trabajando en un diseño y una parte específica de un sistema requiere algo que se ajuste a un patrón de diseño que tenga, entonces úselo. No intente adaptar un sistema a un patrón de diseño, ajuste los patrones de diseño en su sistema (donde quepan). Intente pensar en ellos como un conjunto de soluciones para reducir la cantidad de trabajo de diseño que necesita hacer, y tenga cuidado de no sobre-diseñar sus soluciones para incorporar tantos patrones de diseño como sea posible. Esto solo servirá para que su solución no se pueda mantener y probablemente sea un poco problemática.
Estoy de acuerdo en que solo aprender los patrones no es suficiente. El problema con la mayoría de los libros es que no proporcionan ejemplos del mundo real. He oído que Head First Design Patterns, como algunos sugirieron anteriormente, es bueno.
Otra cosa es que la mayoría de los libros no son intencionalmente específicos del idioma , lo que puede ser bueno o malo para ti. Por importante que sea comprender un patrón en general, es igualmente importante saber cómo implementarlo bien . Me he encontrado con un libro llamado C # 3.0 Design Patterns que dedica casi la misma tinta a estos dos aspectos inseparables.
Experiencia. Aprenda los patrones y ejemplos del mundo real de sus usos. Cada vez que tenga que tomar una decisión de diseño, piense si un patrón que conozca se aplicaría a él. Con el tiempo, mejorará y descubrirá nuevas formas de aplicar los patrones a una gama más amplia de problemas.
Hay un concepto central que subyace a los patrones que la mayoría de la gente no asimila. No pienses en ellos como estructuras de datos o algoritmos.
En cambio, piense en su código como personas que envían mensajes, como pasar notas o enviar cartas, el uno al otro. Cada objeto es una ''persona''.
La forma en que organizarías la ''gente'' y los patrones que usan para enviar mensajes entre ellos son los patrones.
Otro gran libro que encontré fue:
Refactorización de patrones
Al mostrar cuándo, dónde y cómo puede alterar el código existente para patrones, me dio una mejor comprensión de los conceptos, y una capacidad para identificar dónde se pueden usar.
Recomiendo leer Head First Design Patterns de O''Reilly. Esto explica cómo estos patrones se pueden usar en el mundo real.
También agregaría que no intentes diseñar demasiado con los patrones en mente. Más, busque "códigos de olores" que un patrón podría ayudar a resolver.
Rian van der Merwe escribió un excelente artículo sobre esto para Smashing Magazine en junio de 2012. Aquí hay algunos puntos sobresalientes.
Los patrones de diseño son útiles por dos razones:
- Los patrones ahorran tiempo porque no tenemos que resolver un problema que ya ha sido resuelto.
- Los patrones hacen que la Web sea más fácil de usar porque, a medida que la adopción aumenta entre los diseñadores, los usuarios se acostumbran a cómo funcionan las cosas, lo que a su vez reduce su carga cognitiva cuando se encuentran con elementos de diseño comunes.
van der Merwe recomienda que consideremos romper patrones cuando:
- La nueva forma empíricamente mejora la usabilidad, o
- El camino establecido se vuelve obsoleto.
Si conoce los patrones, entonces se convierten en herramientas en su caja de herramientas. Cuando mira una tarea, selecciona de sus herramientas. En ese momento, debe tener una idea bastante aproximada de qué herramienta es la más adecuada para un problema determinado. Aquí es donde las fórmulas dejan de funcionar y usted realmente hace trabajo de ingeniería.
Tuve la misma pregunta cuando me encontré por primera vez con los patrones de diseño. Aprecié los conceptos, pero no sabía cuándo ni cómo aplicarlos. Mi enfoque inicial fue buscar la aplicabilidad durante la fase de diseño. Una vez que tiene un diagrama de bloques y responsabilidades semi-claras para cada bloque, no es demasiado difícil tomar las responsabilidades y hacer una referencia cruzada con un libro de referencia decente. Se han mencionado varios buenos aquí, pero el GoF debería estar en su lista. El siguiente paso es buscar mejoras en el diseño en función de lo que ve en los patrones.
Un patrón de diseño es una descripción genérica de cómo resolver un problema común . Hay dos cosas a las que debemos prestarle atención:
Primero, es una descripción genérica ; no es la solución concreta, y tampoco es una receta completa, es solo una descripción de cómo se vería la solución para abordar un problema común.
Segundo, el problema es que la pregunta es un problema común: eso significa que este problema se ha encontrado muchas veces antes, y con el tiempo las personas desarrollaron una descripción de cómo se puede aplicar una solución ideal a este problema comúnmente repetido.
Por lo tanto, si se encuentra con un problema nuevo que no es común, trate de no usar patrones de diseño para resolverlo, o al menos no haga de los patrones de diseño su herramienta para simplemente resolver cualquier tipo de problema que enfrente.
Vuelva la pregunta: el patrón que debería estar haciendo es "qué patrón se ajusta a mi problema". Considere un patrón realmente simple, encontrando un elemento en una matriz. en C, es algo como
TYPE_t ary[SIZE] = // ... gets initialized somehow
size_t ix ; // Your index variable
for(ix=0; ix < SIZE; ix++){
if (ary[ix] == item) {
return ix ;
}
}
No miras el código y piensas "¿dónde puedo usar eso?", Miras el problema y dices "¿sé cómo encontrar un elemento en una matriz?"
Con patrones más extensos, realmente funciona de la misma manera. Necesita tener muchas copias de una estructura de datos que no cambie a menudo --- que le hace pensar "Flyweight". Si quieres algo que viva a ambos lados de un límite de red, piensas en Proxy.
Cuando estudies los patrones, especialmente el GoF, pregúntate "¿qué situaciones requieren este patrón? ¿He visto este patrón antes? ¿Para qué podría haber usado esto en trabajos anteriores? ¿Dónde puedo encontrar un ejemplo de esto en mi propia vida? "
Se supone que los patrones de diseño proporcionan una estructura en la cual los problemas pueden ser resueltos. Al resolver un problema real, debe considerar muchas variaciones pequeñas de una solución a ese problema para ver si alguno se ajusta a un patrón de diseño. En particular, probablemente necesite generalizar su problema, o su solución, para hacer que un patrón de diseño encaje.
La respuesta es, es un arte. Conocer los patrones de diseño es sin duda un paso importante. Una forma de acostumbrarse a este tipo de cosas es estudiar las aplicaciones de los patrones de diseño, no solo los patrones. Ver muchas aplicaciones diferentes de un patrón puede ayudarlo con el tiempo a mejorar al mapear una tarea en un patrón.