La mayoría de nosotros ya hemos utilizado los patrones casuales como MVC, strategy, etc.¿Cuál es el patrón de diseño más interesante que hayas conocido?
Pero tiene que haber algunas soluciones inusuales a problemas inusuales, y me gustaría oír hablar de eso.
Crash Sólo software: http://www.usenix.org/events/hotos03/tech/full_papers/candea/candea_html/ Resumen
Crash-sólo los programas se bloquean de forma segura y rápida recuperación. Solo hay una forma de detener este tipo de software, al bloquearlo, y solo una forma de hacerlo, iniciando la recuperación. Los sistemas solo de bloqueo se crean a partir de componentes de solo bloqueo, y el uso de reintentos de nivel de componente transparentes oculta las fallas de los componentes internos del sistema por parte de los usuarios finales. En este documento abogamos por un diseño de solo bloqueo para sistemas de Internet, que demuestre que puede generar un código más confiable y predecible y una recuperación más rápida y efectiva. Presentamos ideas sobre cómo construir dichos servicios de Internet de solo fallos, llevando las técnicas exitosas a su extremo lógico.
No, eso es sobre libros DP y este hilo trata sobre los patrones particulares.
Me viene a la mente el intérprete y el peso mosca del libro Gang of 4.
Considero que Bridge y Mediator son patrones potentes y profundos en la caja de herramientas del desarrollador de sw.
Es más un antipatrón, pero he visto lo que llamo el patrón "Mantener todo en un solo lugar". Era una aplicación grande, donde todas las variables que no eran locales, para cada clase, CADA clase, se almacenaban en una única clase llamada P (para parámetros). Como un aparte, todas las variables estáticas se mantuvieron en una clase llamada ... espere ... S.
De todos modos, de alguna manera, este proyecto creció bastante grande, y de repente, nada funcionó. (Me contrataron por esta vez). Sorprendentemente, el programa no falló, solo tenía toneladas de efectos secundarios que hicieron que la aplicación se volviera loca. Como se puede imaginar, múltiples hilos, todos acceden a P y modifican variables, sin bloqueos ni sincronización en su lugar.
Te digo, fue realmente un espectáculo para la vista.
La compañía abrió una nueva oficina y contrató a 3 personas para su personal, yo soy uno de ellos. Nos dieron el programa y nos dijeron que lo arreglaran. Pasamos días sentados solo abofeteando nuestras cabezas. Tengo una impresión de palma permenente en mi cara ahora.
Otros divertidos ... variable llamada "fudgeFactor". Todavía no sé lo que hizo.
método para conseguir siguiente carácter ASCII ...
char getNextChar(char previous) {
switch (previous)
case 'a': return b;
case 'b': return c;
...
case 'z': return a;
}
De todos modos, esa es mi patrón divertido ... con un poco de extra lado divertido tirado.
Me recuerda alguna publicación sobre "el wtf diario" :-) –
Visitante me pegó por primera vez cuando se trabaja en un programa con muchos gráficos, como una forma muy elegante de hacer operaciones en estructuras complejas.
además de mvc (que no es un pattenr per se), este es el "rey de los patrones" en cuanto a su complejidad y potencial para resolver problemas.
El Fluent Interface de Fowler es un patrón bastante interesante. Siempre he tenido un punto débil para Abstract Factories, Strategies y State Pattern también.
Si puedo, recientemente codifiqué un "patrón" que llamo el Friend Class Pattern que algunos pueden encontrar interesante o útil para restringir la visibilidad de los accesos de campo privados en idiomas que no tienen clases de amigos de estilo C++.
Hmm, Fluent. Linq es construir para eso. – Dykam
No sé si describiría a Linq como una interfaz fluida. En mi experiencia, las interfaces fluidas generalmente están diseñadas para que las llamadas puedan leerse como una frase en inglés. Los métodos de una interfaz fluida a menudo son extremadamente estables: llamar al mismo método en diferentes momentos produce resultados tremendamente diferentes. Linq se trata más bien de componer una tubería que se usará para procesar un conjunto de datos. Ninguno de los métodos de Linq muta ningún estado; simplemente devuelven un nuevo objeto. Y los métodos de Linq se sienten más como "método" que como "frase" y para mí. Pero esa es solo mi opinión. –
El patrón de diseño más interesante que conocerá es uno que haya creado usted mismo, por razones obvias.
Eso no quiere decir que sea el mejor diseño, solo el más interesante.
Yo no. Una vez que he creado algo, incluso si estoy bastante orgulloso de él, se vuelve trivial y, por lo tanto, completamente carente de interés. Son cosas con las que aún no estoy familiarizado que son interesantes. – ChrisA
Nunca vi el punto del patrón Visitor hasta que tuve que manipular el bytecode de Java directamente usando la biblioteca ASM. Fue sorprendente cuánto simplificó el patrón lo que de otra manera hubiera sido una tarea realmente compleja.
El patrón también se utiliza en la mayoría de los IDE de Java cuando desea escribir su propio complemento de refactorización. Proporciona un objeto Visitor y se pasa alrededor del AST para realizar los cambios necesarios.
No es tanto un patrón, pero la inyección de dependencia y la inversión de control
Para el último año he estado haciendo el mantenimiento de una aplicación de Windows escrito en LANSA donde el foco es administrado por tener todos los controles establecidos a TabStop = falso excepto por dos botones ocultos (PrevFocus y NextFocus). Cuando se carga un formulario, el foco se establece en un campo, y el nombre de ese campo se almacena en una variable de seguimiento (denominado "FocusField"). Cuando las pestañas del usuario (o pestañas de desplazamiento) cambian el foco, se ejecuta el evento GotFocus del botón apropiado. Dentro de esa función hay una declaración de caso (seleccione el caso FocusField). En función del campo actualmente enfocado, se ejecuta la lógica de validación y, posiblemente, el foco cambie a otro campo.
Los eventos GotFocus para la mayoría de los controles miran cuál es el valor actual de FocusField y luego llaman a una función LostFocus que hace que el mismo enunciado de caso funcione para FocusField para que el campo previamente enfocado sea validado.
Como probablemente pueda adivinar, esto hace que sea imposible separar la interfaz de usuario de la lógica, y una tarea increíble de mantener. Volver a escribir estos formularios para usar un método de validación simple que valide TODAS las entradas y permita que las propiedades de tabulación normales (TabOrder, TabStop, etc.) hagan su magia generalmente ha resultado en una reducción del 50% en el código y formas mucho más confiables.
No tengo idea de dónde se originó este patrón, aunque puede haber sido ideado por los programadores RPG/pantalla verde convertidos en desarrolladores de WinForms que escribieron la aplicación.
Recuerdo cuando leí por primera vez sobre el flyweight pattern en el GOF. El ejemplo que usan es un procesador de textos; señalan los inconvenientes de usar un objeto independiente para representar a cada personaje. El patrón de peso mosca fomenta la separación del estado compartible, intrínseco e inmutable del estado mutable, extrínseco e inalterable. Para mí, en ese momento, era uno de esos "Aha!" momentos que realmente ampliaron mis horizontes y han afectado mis diseños hasta el día de hoy.
Un amigo mío sugirió que el patrón de Estrategia es esencialmente el patrón progenitor. Muchos de los otros patrones (Bridge, Decorator, Proxy, State, ...) son simplemente aplicaciones más refinadas de Strategy. Recuerdo haber discutido con él durante bastante tiempo que, de hecho, hay una diferencia entre Estrategia y Estado.
Me gusta su publicación, pero puede agregar una explicación sobre el patrón que está describiendo. –