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 averiguar 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?¿Cómo sabe cuándo utilizar patrones de diseño?
En otras palabras, ¿hay patrones para Patrones?
Se supone que los patrones de diseño proporcionan una estructura en la cual se pueden resolver los problemas. Al resolver un problema real, debe considerar muchas pequeñas variaciones de una solución a ese problema para ver si alguna 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 que 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 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.
Recomiendo leer Head First Design Patterns de O'Reilly. Esto explica cómo estos patrones se pueden usar en el mundo real.
También me gustaría añadir que no tratan de diseño demasiado con patrones en mente. Más, busque "códigos de olores" que un patrón podría ayudar a resolver.
Sí, tengo ese libro. Es muy bueno. No me importan los ejemplos (patos, pizza y otras cosas), pero ofrece una base sólida para los patrones de diseño. –
Pero los ejemplos en este libro (con pizzas, fábricas de chocolate, etc.) realmente te ayudan a comprender el concepto y la idea de cada patrón. –
Parece que el patrón de diseño se inyecta en el cerebro. Realmente un libro increíble. – Jnana
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.
Y uno de los mejores lugares para aprender cómo reconocer patrones de diseño es en un Dojo de Codificación, donde los participantes se involucran en una "práctica deliberada" con problemas de juguete (ver http://en.wikipedia.org/wiki/Kata_(programación)) Los grupos de usuarios locales a veces alojan dojos. Pero, incluso si uno no puede encontrar un dojo para unirse, hay mucho valor en correr solo con katas. –
Otro gran libro que encontré fue:
Refactoring a patrones
Al mostrar cuándo, dónde y cómo se puede modificar el código existente para los patrones, me dio una mejor comprensión de los conceptos, y una capacidad de identificar dónde se pueden usar.
¿Cómo aprendiste cuándo usar una instrucción if?
Lo comparo con eso porque es una construcción más grande que necesita para conocer los pormenores de antes de que pueda usarlo de manera efectiva. 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.
Si conoce los patrones, 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.
Estoy de acuerdo en que simplemente 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 son intencionalmente no específicos del idioma, lo que puede ser bueno o malo para usted. Por importante que sea entender 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.
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.
Patrones de diseño? ¡Estás empapando en ellos!
No hay nada de 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 design anti-patterns), así como patrones no descubiertos y/o no documentados.
No puede evitar el uso de patrones durante la programación. 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 GoF book ayudará, al igual que aprender sobre code smells and refactoring. 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.
Dé la vuelta a la pregunta: el patrón de mtch 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, que es algo así 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 te ves en el código y piensa "en el que puedo usar esa", nos fijamos en el problema y dicen "Yo 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 estudie los patrones, especialmente el GoF, pregúntese "¿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?"
Hay un concepto central que subyace a los patrones que la mayoría de las personas no asimilan. No pienses en ellos como estructuras de datos o algoritmos.
En su lugar, piense en su código como personas que envían mensajes, como pasar notas o enviar cartas, entre sí. Cada objeto es una 'persona'.
La forma en que organizaría la 'gente' y los patrones que utilizan para enviarse mensajes entre ellos son los patrones.
El concepto de patrón de diseño ha sido 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 iguales. 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.
Rian van der Merwe escribió un excellent article sobre esto para Smashing Magazine en junio de 2012. Aquí hay algunos puntos sobresalientes.
Los patrones de diseño son útiles por dos razones:
van der Merwe recomienda que consideramos los patrones de ruptura cuando:
Ese es un tipo diferente de patrón de diseño, pero su respuesta sigue siendo excelente. :) –
Un patrón de diseño es una descripción genérica sobre cómo resolver un problema común . Hay 2 cosas que debemos prestar atención a:
En primer lugar, se trata de un 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.
En segundo lugar, el problema es cuestión es un problema común :, eso significa que este problema se ha encontrado muchas veces antes, y con el tiempo la gente desarrolla una descripción de cómo una solución ideal se puede aplicar a esta comúnmente repetida problema.
Por lo tanto, si se encuentra con un problema nuevo que no es común, trate de no utilizar patrones de diseño para resolverlo, o al menos no haga de patrones de diseño su herramienta para resolver cualquier tipo de problema que enfrente.
¿Cómo estudiar diferentes aplicaciones cuando no están documentadas? En el mundo real aplicamos y seguimos adelante. ¿Cómo encontrar esa fuente donde podemos estudiar sobre la aplicación exitosa antes de aplicar? ¿Dónde está la fuente? –
dale una cerveza a este hombre. – user1262904