Patrones de Diseño - Arquitectura astronauta

Question

Tal vez mi pregunta es de naturaleza similar a ésta: Do you use design patterns?

Los programas que escribo son pequeños programas de línea de 50-75 K en su mayoría utilizando Windows Forms y ASP.NET. Estos programas son intensivos en GUI, lo que permite el diseño y la disposición de varios gráficos y procesamiento de gráficos.

Me considero bueno en OOP y practicado para equilibrar OOP y métodos de procedimientos tradicionales para crear código que se pueda mantener.

El problema aparece cuando considero los patrones de diseño. The linked to thread tiene un comentario interesante de que los patrones de diseño pueden usarse pero no intencionalmente. Cuando quiero utilizar intencionalmente un patrón de diseño (en el diseño de mi programa), siento que estoy yendo más allá de lo que es necesario, que estoy en el ámbito de "architecture astronaut", así que vuelvo a mi estilo tradicional. métodos y todo transcurre sin problemas (es decir, normalmente).

Tome el patrón MVC como ejemplo. Si quiero implementar este patrón usando Windows Forms o ASP.NET (Visual Studio 2005), entonces tengo que escribir un "Framework" y escribir frameworks parece ser más problemático que lo que vale para el tamaño de la aplicación.

Quizás mis aplicaciones sean demasiado pequeñas para justificar el uso de algunos de estos patrones. Tal vez simplemente no conozco los patrones lo suficientemente bien o necesito estudiarlos más.

¿Alguien más experimenta este sentimiento de "astronauta de la arquitectura"?

¿Cómo se hace para usar intencionalmente patrones de diseño sin ir "al agua"?

Answer 1

Cuando se trata de aplicaciones más pequeñas de esta naturaleza, generalmente me preocupo más por anti-patterns que por los patrones de diseño. Dicho esto, en realidad son dos caras de la misma moneda: para mí, el poder de un patrón de diseño es familiarizarme con ellas para reconocer los pros y contras menos que obvios de cualquier solución en la que esté pensando. Raramente, si es que alguna vez salgo de mi camino, para implementar completamente un patrón de diseño completo (a menos que realmente necesite toda la funcionalidad); sin embargo, a menudo me he ahorrado muchas reconstrucciones futuras al reconocer el camino que estoy tomando y al observar las trampas o desventajas comunes de esa solución, que luego puedo verificar contra mis usos futuros para ver si va a ser una preocupación relevante para mí o no. Por lo tanto, el poder de un patrón de diseño es que usted puede predecir fácilmente las consecuencias futuras de su solución actual contra sus necesidades potenciales, sin preocuparse de que le falte alguna advertencia o caso especial que no haya considerado.

Answer 2

MVC, en sí mismo, no requiere que escriba ningún marco. Simplemente significa que mantiene su vista, controlador y código de modelo separados. Utilizo MVC (o MVP) incluso para aplicaciones móviles simples, ya que la separación del control me resulta enormemente ventajosa cuando escribo pruebas (sin mencionar cuando cambio de UI).

Supongo que no se realizan muchas pruebas de integración o de integración en este momento, por lo que no está tan claro cuánto hace que esta división ayude a la calidad y la legibilidad de su código.

Le recomiendo que lea Fowler's coverage of UI architectures.

Answer 3

Para mí, depende de:

• El tamaño de la aplicación,
• El patrón de diseño que se utilizará,
• La cantidad de tiempo que tengo que invertir por adelantado en la arquitectura.

En una aplicación pequeña, es mucho menos probable que use patrones de diseño que no fluyan de forma natural a menos que tengan un gran ROI en el ámbito de expansión o mantenimiento de la aplicación.

Answer 4

Estás trabajando en un entorno en el que una empresa grande establece los patrones, y creo que esto explica tus sentimientos. Y probablemente tengas razón. Aquellos de nosotros que usamos los lenguajes de FOSS en entornos abiertos para problemas más amplios, tenemos infinitas opciones, y leer en patrones de diseño nos ayuda a tomar decisiones informadas sobre la arquitectura. Por lo general, esto significa elegir las bibliotecas correctas. Sus elecciones para el dominio restringido en el que está trabajando se han hecho para usted.

Answer 5

Los patrones están ahí como soluciones abstractas para problemas generales. Si uno conoce los patrones, entonces tiene una mayor probabilidad de aplicar una solución conocida, más rápido, y no quedarse sentado pensando: "Caramba, me pregunto cómo hacer que esto funcione".

En cuanto a los marcos: si trabajaste en un equipo de más de una persona (que no suena como si lo hubieras basado en el tamaño pequeño de tus proyectos), los marcos pueden ayudar a todos a hacer las cosas manera importante, lo que es importante en un esfuerzo grupal por la capacidad de mantenimiento y para que las nuevas personas se pongan al día rápidamente.

Answer 6

mi humilde opinión, se necesita tener:

1. Una buena comprensión de los pros & los contras de diferentes diseño patrones que puede utilizar
2. claridad de lo que su aplicación está diseñada para hacer y hacer de que el los pros del patrón se usan para su ventaja.

Tome el patrón MVC como ejemplo. Si quiero implementar este patrón usando WinForms o ASP.NET (VS 2005) entonces que escribir un "marco" y marcos de escritura parece ser más problemas de lo que vale para el tamaño de la aplicación.

¿Su aplicación web necesita un SEO efectivo? El patrón MVC implementado para ASP.NET podría ayudar en este sentido. Tome SO SO por ejemplo. Están tan bien optimizados para los motores de búsqueda principalmente porque la implementación del patrón MVC para ASP.NET lo apoyó y se ha utilizado eficazmente en el diseño/desarrollo de SO.

Answer 7

'¿Cómo se puede ir sobre intencionadamente utilizando patrones de diseño sin tener que pasar 'por la borda?''

fácil.

1. No combine un esfuerzo de desarrollo de la estructura MVC con patrones.

2. Reconozca que cada cosa que hace ha sido hecha anteriormente (por usted o por otra persona).

3. Cuando repite algo, cualquier cosa, sigue un patrón.

4. Cuando repite el diseño para cualquier cosa, por pequeño que sea, sigue un patrón de diseño.

5. Cuando se da cuenta repitiendo algo, asigne un nombre a esa cosa que está repitiendo. Mira, has descubierto y nombrado tu primer patrón de diseño. No importa que tan pequeño.

6. Cuando ha nombrado un patrón de diseño, puede pensar cuándo lo usa, por qué lo está usando, qué soluciona y cuáles son las consecuencias de su uso. No importa que tan pequeño.

7. Cada pieza de aprendizaje que implica "repetir elementos de diseño" es patrones de diseño. No importa que tan pequeño.

Every loop. Cada declaración if. Cada cuadro de diálogo. Cada archivo abierto Estos son todos los patrones de diseño.

La mayoría son parte del lenguaje y tienen nombres específicos del lenguaje obvios. "SI", "ABIERTO", etc.

Algunos patrones de diseño son más grandes que un solo enunciado, pero más pequeños que todo el marco MVC. Esos son los interesantes. Aprende ésos. Compra un libro. Léelo. MVC no aparecerá en la mayoría de los libros de patrones de diseño porque, bueno, es demasiado complicado y difícil de aplicar.

No comience con MVC. Comience con CUALQUIER COSA más.

Answer 8

Casi cualquier patrón de diseño adecuado, cuando se aplica, debe resultar en la simplificación. Si estás haciendo las cosas más complejas, probablemente te dirijas en la dirección incorrecta para tu problema específico.

Answer 9

Los problemas simples a menudo requieren soluciones simples, aunque algunos problemas difíciles son muy simples. Los problemas complicados, por otro lado, podrían resolverse de manera organizada o mediante un código sucio de espagueti. Muchos han intentado organizar los diseños del software y algunos de los "patrones" surgieron y obtuvieron los nombres.

Creo que los patrones son un vocabulario útil cuando se comunica el propósito de su diseño a otros, pero no es algo que se meta en el diseño. A medida que desalinea el código según sea necesario, aplica patrones según sea necesario. Por ejemplo, poner en el patrón de generador cuando te encuentras constructor muy complicado.

Desconectar la capa de datos y la capa de interfaz de usuario de su lógica de negocio para mí es algo que debe hacer con un diseño igual de bueno. Nuevamente, el objetivo es el acoplamiento bajo, DRY y el código de mantenimiento, no los patrones.

Answer 10

"astronautas de la arquitectura" son aquellos que pasan mucho tiempo discutiendo sobre el diseño pero que en realidad no logran que suceda.

Me gustan los enfoques de los patrones de diseño presentados en el libro "Refactorizar a patrones". Aquí, los patrones no son algo en lo que se invierta por adelantado, sino algo que hacemos para reducir la complejidad del código solo después de que se interpone en el camino. Debido a que este enfoque requiere un código funcional para comenzar, y selecciona refactorizaciones basadas en lo que haría más fácil extender ese código para cumplir un requisito en particular, sus resultados se enfocan mucho.

Answer 11

No se olvide de la comunicación: los patrones de diseño bien conocidos le permiten comunicar algo complejo con solo unas pocas palabras. Cuando dice "y las notificaciones se entregan usando el patrón de observador", todos saben a qué se refiere.

Answer 12

Muy pocos proyectos requieren o se benefician de la arquitectura hiper. La mayoría de los proyectos que comienzan de esa manera nunca se completan. Muchos de los que tienden a ser muy difíciles de extender o mantener (a pesar de sus afirmaciones de lo contrario). Y recuerde qué tan rápido evolucionan los idiomas y las tecnologías. Lo más nuevo y genial de hoy puede estar desactualizado para cuando termine un proyecto muy grande. Los patrones son interesantes y pueden darle una idea de cómo resolver un problema de forma elegante, pero la mayoría de las veces, en el mundo real, no hay una solución elegante. En todas partes donde he trabajado alguna vez ha habido un astronauta súper estrella, impresionando a todos arrojando una jerga interminable mientras escribo código basura que tendré que arreglar más tarde. El resultado final es lo más importante. Su empresa necesita una aplicación que funcione, no un trabajo interminable en progreso, incluso si ellos mismos no se dan cuenta.