¿Qué debe venir primero: el patrón de diseño o el código?

Question

Empiezo con un nuevo proyecto. ¿Debería consultar mis especificaciones y decidir qué patrones de diseño aplicar, o simplemente presentar una idea general de la organización y permitir que los patrones surjan de manera orgánica a través de la refactorización?

En su experiencia, qué técnica será más productivos y tienen una mayor probabilidad de conducir a limpiar código elegante?

También me pregunto si hay patrones de diseño por ahí que no están definidos por el GoF, pero podría ser tan valioso? Si es así, ¿cuáles son algunos recursos útiles para informarme sobre esto?

Answer 1

Debe hacer crecer su código de forma orgánica, aplicando patrones a medida que se ajusten. Hacer coincidir los patrones demasiado pronto puede generar una gran cantidad de código inapropiado y tantas capas de abstracción que el diseño se ofusca. Sea testigo de cualquier código que has visto que fue escrito patrones de la derecha después de que alguien había descubierto por primera vez ;-)

Answer 2

1. averiguar los casos de uso.
2. Piense en el diseño que busca en todo el patrón de diseño existente.
3. Comience a implementar.

Creo que el objetivo principal aquí es evitar reinventar la rueda.

PS. Después de pasar el paso 2 durante un tiempo y acostumbrarse, podrá integrar ese paso en el paso 3.

Answer 3

A menos que un patrón parezca salirse de la especificación, no necesariamente probaría para elegir algo de GoF y resolver el problema hasta que se ajuste al patrón.

Es mejor entender conceptualmente los diferentes niveles de abstracción en la cabeza y llegar a un plan (no necesariamente un patrón de diseño popular) para saber cómo llevarlo a la práctica. Esto es algo que mejorará con la experiencia. Si bien conocer los patrones de GoF te ayudará a mejorar tu capacidad de pensar en problemas en términos de diseño de códigos, no están destinados a ser soluciones para todos los problemas, y forzar artificialmente tu problema para que encaje en un patrón de diseño puede significar complicación y ofuscación innecesarias.

Answer 4

usted debe tener una comprensión de lo que los patrones encajarían el problema antes de empezar a programar. Si no, crea un prototipo para que entiendas lo que quieres lograr. Luego busque patrones y deseche (la estructura de) el prototipo (y reutilice los bits buenos).

Answer 5

Si alguna vez no estoy seguro solo empiezo a escribir el código. En poco tiempo, la estructura comenzará a suplicar por alguna refactorización y la elección es casi siempre obvia.

Aunque a veces me siento inspirado por un patrón particular, es casi siempre el código que me muestra el camino correcto.

También estoy no tiene miedo de incendiar y reconstruir partes de un programa. Hay una cita que me gusta mucho de Scott Adams: "La creatividad te permite cometer errores, el arte es saber cuáles conservar". A veces, la respuesta correcta no es obvia hasta que lo intentas de la manera incorrecta.

Answer 6

Buen consejo aquí ya. Para responder la pregunta sobre patrones útiles que no sean el libro de GoF. Hay, deberías verificar la aplicación de UML y patrones de Larman donde describe los patrones GRASP.

Answer 7

Me mantendría alejado de modelar demasiado su código según el uso del patrón de diseño inicial. Es mejor simplemente hacer código simple y cuando sea necesario refactor towards a design pattern que luego captura mejor sus necesidades.

Answer 8

Debe hacer crecer su código de forma orgánica, aplicando los patrones que le queden.

¡Con conexión! Algunos de los peores espaguetis que he visto son OO C++ con muchos patrones. Fluxbox es apenas soportable; Sinergia (v2) hervir, asa y hornea mi fideos :(

Y algunos de los códigos más bella que he visto es OO C, en el que el OO era dos interfaces más 4 y 20, respectivamente implementaciones.