principios - facade design pattern c#
Principios sólidos y compilación? (7)
Por ejemplo, en relación con el principio de Single Responsibility :
Hablemos de una clase de Radio :
Se podría argumentar que la clase de Radio tiene dos responsabilidades, que son el volumen y la gestión de estaciones. Estas operaciones serán llamadas desde áreas completamente diferentes del cliente que lo utilizan.
por lo tanto tenemos esto:
Todo muy bien.
Pero siempre veo frases como estas:
Así que ahora, cuando necesitamos un cambio , no es necesario volver a compilar todo el código que depende del componente roto.
Espera un minuto !
Si necesito cambiar la clase VolumeManager , no tendré que volver a compilar Radio y StationManager . Pero tendré que detener (en la web) el iis para que la aplicación use la nueva DLL, y esto causará que la aplicación se caiga .
Además, en la console , tendré que terminar todo el programa para cambiar la dll ya que está bloqueado por el proceso (no se puede cambiar la dll cuando la aplicación se está ejecutando, el archivo está bloqueado)
Incluso cuando use el GAC, tendré que detener el programa para que el archivo dagne sea chagne.
Entonces, ¿qué me salva? compilar es simplemente - haga clic derecho y construir. eso es todo
No veo el beneficio de mencionar: " necesitarás compilar solo la clase rota ... "
Qué me estoy perdiendo ?
http://www.gontu.org/solid-single-responsibility-principle/ busca la palabra " build "
http://epic.tesio.it/doc/manual/solid_principles.html busque la palabra " recompiled "
http://www.dananhudson.com/?tag=solid busque la palabra " recompile "
Creo que lo importante a tener en cuenta con los patrones de diseño es la flexibilidad. Si alguna vez decide implementar varios tipos de StationManager y VolumeManager, no tendrá que cambiar ningún código en su clase de Radio. El único cambio será impuesto por la instanciación de la clase Radio. Para esto, todavía tendrá que reiniciar su aplicación, pero no tendrá ningún código de espagueti en su clase, con varias instrucciones if-else. Ningún código cambiará, solo agregará un nuevo código para las nuevas clases. Esto también obedece a otro principio de diseño importante: el principio abierto / cerrado (la O en SOLID): el código debe estar abierto por extensión, pero no por modificación. Aunque siga todas las buenas prácticas de diseño, deberá reiniciar la aplicación para que se realicen los cambios.
El tiempo de compilación no es un problema en C # en comparación con C ++. Un gran proyecto de C ++ puede tardar años en compilarse. Se vuelve realmente frustrante cuando tratar de hacer un cambio en un área causa la recompilación de componentes no relacionados. La responsabilidad única guía hacia dependencias más compactas de esa manera mejorando un problema de compilación.
En realidad, los argumentos relacionados con la compilación y el proceso de compilación no son realmente importantes para la plataforma .NET. Pero puede ser muy importante para alguna otra plataforma y / o idiomas.
Por ejemplo, en el mundo C ++, este beneficio puede llevar a un aumento espectacular de la productividad por parte del equipo de desarrollo, ya que ahorrará horas durante el tiempo de compilación. En el mundo C ++, el lenguaje Bridge Pattern o Pimpl puede ahorrar mucho tiempo, porque cada cambio en el archivo del encabezado (incluso en la parte privada) dará lugar a la recompilación de todas las dependencias (directas o indirectas). En este caso, el aspecto de compilación o compilación de los principios de SOLID puede ser realmente beneficioso.
En pocas palabras, los principios de SOLID no se refieren al proceso de compilación ni a la compilación, sino a las dependencias. Pero cuando maneja sus dependencias adecuadamente, definitivamente también ganará en esas áreas (incluyendo, pero limitando los procesos de compilación y compilación).
Hay situaciones en las que es "políticamente" más fácil implementar una actualización en una aplicación existente si puede demostrar que los cambios tienen un alcance limitado: si solo se tiene que actualizar una DLL, por ejemplo. (tenga en cuenta que esto no significa que cada clase deba estar en su propia DLL. Pero lo más probable es que no todas sus clases estén en la misma DLL)
Sin embargo, la otra ventaja es más conceptual : si no tengo que volver a compilar una DLL, entonces estoy seguro de que no rompí nada en ella. Cuanto menos se toque el código, menos posibilidades hay de que yo introduzca un error.
No creo que la compilación guardada sea lo que importa, sino por qué podrías escapar sin ella.
Porque un cierto cambio está contenido en un área limitada de su aplicación. Esto es algo bueno en sí mismo: en un sistema bien diseñado no tengo que entender la aplicación completa para cambiar su comportamiento y creo que eso es lo que importa.
El hecho de que las dlls estén bloqueadas o que IIS reinicie el grupo de aplicaciones afectado (lo que hace bastante bien, podría decir) son tecnicismos que pueden ser mitigados en algún sistema futuro.
De hecho, con algunas instantáneas y App-Domain hokey-pokey puedes escribir un programa que no necesitarías reiniciar cuando intercambies un archivo DLL.
Olvida el tiempo de compilación, olvida el reinicio de la aplicación.
SOLID es sobre código limpio y mantenibilidad. No se trata de nada en el tiempo de ejecución, se trata de que el código se complique con el tiempo y sea difícil de mantener, y ahí es donde está el costo real.
Recomiendo altamente los videos de codificadores limpios de Uncle Bob sobre los principios de SOLID.
La idea principal detrás de la implementación independiente es que los módulos que pueden implementarse de manera independiente también pueden desarrollarse de manera independiente . Por lo general, no implementa módulos de forma independiente, pero sí se beneficia de poder desarrollarlos de manera independiente.
En relación con los efectos en el proceso de compilación, esto probablemente sea relevante en C ++, donde cada unidad de compilación (archivo cpp) tendrá que volver a compilarse cuando el código dependa de los cambios y donde un gráfico de dependencia cuidadosamente construido, donde un cambio afecte solo a una unidad de compilación , puede afectar seriamente el tiempo de compilación. De todos modos, a menos que esté trabajando en un hardware antiguo, probablemente no debería dar prioridad al tiempo de compilación.
Acerca de tener que detener la aplicación (web o consola) cuando se modifica e implementa un módulo independiente; esto se puede evitar mediante el uso de un marco de plugin, que puede cargar de forma dinámica conjuntos nuevos / modificados en la aplicación, y los principios de SOLID se pueden aplicar a la aplicación. Cómo construyes los complementos y sus interfaces. Tenga en cuenta que esto podría agregar más complicaciones, y recomendaría evitar esto y simplemente reiniciar la aplicación en la implementación.