design-patterns - software - patrones de diseño web

Patrones de diseño-Arquitectura Astronauta (12)

Quizás mi pregunta es similar en naturaleza a esta: ¿Usas patrones de diseño?

Los programas que escribo son pequeños programas de línea de 50-75 K, principalmente con 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 practiqué 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 voy más allá de lo necesario, que estoy en el ámbito de la " astronauta de arquitectura ", así que recurro a mi métodos tradicionales y todo transcurre sin problemas (es decir, normalmente).

Tome el patrón MVC como un 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 son 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 manejas intencionalmente patrones de diseño sin ir "por la borda"?

''¿Cómo se hace intencionalmente usando patrones de diseño sin ir "por la borda?''"

Fácil.

No combine un esfuerzo de desarrollo de un framework MVC con patrones.
Reconozca que cada cosa que hace ha sido hecha anteriormente (por usted o por otra persona).
Cuando repites algo, cualquier cosa, sigues un patrón.
Cuando repites el diseño para cualquier cosa, sin importar cuán pequeño, sigas un patrón de diseño.
Cuando te das cuenta de que estás repitiendo algo, asigna un nombre a esa cosa que estás repitiendo. Mira, has descubierto y nombrado tu primer patrón de diseño. No importa que tan pequeño.
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.
Cada pieza de aprendizaje que implica "repetir elementos de diseño" es patrones de diseño. No importa que tan pequeño.

Cada ciclo 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 obvios específicos del lenguaje. "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 empieces con MVC. Comience con CUALQUIER COSA más.

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

Cuando se trata de aplicaciones más pequeñas de esta naturaleza, generalmente me preocupo más por los anti-patterns 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.

En mi humilde opinión, uno debe tener:

Una buena comprensión de los pros y los contras de los diferentes patrones de diseño que podrías usar
Claridad sobre lo que su aplicación está diseñada para hacer y asegúrese de que los pros del patrón se utilicen a su favor.

Tome el patrón MVC como un ejemplo. Si quiero implementar este patrón usando WinForms o ASP.NET (VS 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.

¿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.

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.

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

Me gustan los enfoques de los patrones de diseño presentados en el libro "Refactor 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.

Los patrones están ahí como soluciones abstractas a 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 (lo cual no parece que hayas basado en el tamaño pequeño de tus proyectos), los marcos pueden ayudar a que todos hagan las cosas de la misma manera, lo cual es importante en un esfuerzo grupal por la mantenibilidad y rápidamente poniendo a las personas nuevas al día.

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 comunicas tus intenciones de 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 empresarial para mí es algo que debería hacer con un diseño tan bueno. Nuevamente, el objetivo es el código de bajo acoplamiento, DRY y mantenible, no los patrones.

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 en este momento no se realizan muchas pruebas de unidades o de integración, por lo que no es tan obvio cuánto hace que esta división ayude a la calidad y la legibilidad de tu código.

Le recomiendo que lea la cobertura de Fowler de las arquitecturas UI .

Muy pocos proyectos requieren o se benefician de la hiper arquitectura. 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.

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.

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 para invertir por adelantado en arquitectura.

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