¿Cómo determinar si el patrón de diseño se implementa correctamente?

Puedo escalar con éxito todas mis aplicaciones antiguas que no usaban patrones de diseño documentados. Sea cual sea el patrón, no lo sé. En gran medida, solo sentí la necesidad de usar conceptos simples de OOP.

El concepto de Patrones de diseño es complejo y difícil de entender. Cuando se implementa, ¿cómo determinar si la implementación es correcta y si la aplicación posee un acoplamiento real suelto?

Para mantener la respuesta concisa, diría que si las siguientes características son visibles en su código, puede estar seguro de que los patrones están en su lugar, incluso si no ha realizado esfuerzos deliberados (que no es un problema) hacia él.

Características deseadas:

1. Su código base es comprobable a nivel de unidad
2. Cada vez que implementa cualquier solicitud de cambio, solo realiza cambios en las clases relevantes que se correlacionan en el dominio.
3. Su código base no exhibe entropía de software .

Si todavía tiene curiosidad por identificar y etiquetar su código con los nombres de los patrones reales, le recomendaría realizar las siguientes acciones para que la pelota ruede.

1. Realice ingeniería inversa de su base de código para generar algunos daigramas UML.
2. Compare visualmente los diagramas con cualquier referencia lista de material de referencia de patrones.

Esto debería darte una idea justa.

Usted menciona tanto los patrones de diseño como el acoplamiento. Estos son conceptos separados, así que los trataré por separado. La única conexión real es que los patrones de diseño tienden a promover un acoplamiento flojo (ya que es un aspecto importante del buen diseño).

Patrones de diseño

El concepto de Patrones de diseño es en realidad bastante simple: son solo un conjunto de plantillas sobre cómo tratar varios problemas comunes. Hay 2 razones principales por las que son populares:

1. Están 'probados': se han usado antes muchas veces y los beneficios / inconvenientes de cada uno son generalmente conocidos, en particular, cualquier problema sutil que pueda causar grandes problemas.
2. Proporcionan un conjunto común de terminología y permiten una comunicación más fácil. Si alguien dice que "la clase X desempeña el papel de observador en el patrón de observador", entonces los desarrolladores que estén familiarizados con el patrón pueden comprender de inmediato lo que está sucediendo.

¿Cómo sabes que lo has implementado correctamente? Eso es complicado. Para la mayoría de los patrones es simple: lo has asimilado o no lo has hecho. Algunos patrones están menos claramente definidos que otros, por ejemplo, model-view-controller . Patrones como ese se usan mejor como pautas generales. Los detalles de cómo implementarlo son menos importantes que comprender las razones por las que existe el patrón y lo que se pretende lograr.

Los patrones de diseño no son 'la única forma verdadera'. A menudo necesitará adaptarlos para sus propósitos específicos, o algunas veces simplemente no habrá patrones que se ajusten a los requisitos. Forzar un patrón de diseño donde no encaja es una mala idea; es como usar un martillo realmente bueno cuando lo que realmente quieres es un destornillador.

Acoplamiento

Esta es una idea realmente importante en informática. Dado que los requisitos para la mayoría de los proyectos de software cambian con el tiempo (a veces significativamente), la capacidad de un diseño para hacer frente a los cambios es importante. El acoplamiento es básicamente la medida de "¿qué tan difícil sería cambiar este componente por otro?" El 'componente' podría ser un método, clase, paquete, biblioteca, etc.

Hay varios tipos de acoplamiento enumerados en este artículo de Wikipedia .

La respuesta es en realidad el propósito de que desee escribir patrones de diseño desde el principio. ¿Por qué quieres flexibilidad?

Eso es cambio; cambio de requisitos Intente cambiar algo en sus requisitos que se refleje en el cambio de código y vea cuán fácil / difícil es hacerlo.

Usar patrones de diseño es una acción preventiva. Utiliza patrones de diseño para facilitar su trabajo cuando está escalando la aplicación más tarde. Por supuesto, para facilitar su trabajo más tarde, debe hacer un poco más de trabajo ahora. Entonces, la verdadera pregunta es cuánto cambio puede esperar en el futuro y cuál es este cambio. Si no necesita escalabilidad y flexibilidad, puede eliminar los patrones de diseño.

Los patrones de diseño son en sí mismos una implementación de los Principios de diseño orientados a objetos. Mientras siga estos principios, sus aplicaciones serán flexibles y escalables; incluso si realmente no tienes un patrón de diseño real. Como Joachim Sauer ha comentado anteriormente, son soluciones comunes a problemas comunes.