language-agnostic - ejemplo - programacion orientada a aspectos pdf
¿Qué pasó con la Programación Orientada a Aspectos? (5)
En realidad, AOP es realmente brillante, el problema es que ningún idioma existente tiene un gran soporte para ello. Sure C # tiene atributos (que solo funcionan cuando está CODIFICANDO la cosa) y Java tiene "inyección" (lo que crea un lío en el tiempo de ejecución) pero, en general, no hay idiomas (convencionales) que tengan un apoyo realmente bueno para ello. ..
Así que terminó siendo un "Patrón de diseño" (con implementaciones increíblemente diferentes en todos los diferentes idiomas) que, después de todo, no es tan malo, creo;)
Recuerdo que a fines de la década de 1990 y principios de la de 2000 se suponía que la Programación Orientada a Aspectos (AOP) sería la "Siguiente Gran Cosa". Hoy en día veo algo de AOP alrededor, pero parece haberse desvanecido en un segundo plano.
Eso tiende a suceder con cada "próxima gran cosa". Mucha publicidad, seguida de una disminución lenta en el uso de la palabra de moda. Pero, a pesar de que las palabras de moda se desvanecen y eventualmente desaparecen, cualesquiera buenas ideas que estén detrás de ellas tienden a quedarse para ser absorbidas por la corriente principal.
[ Editar ] Bien, un ejemplo para aquellos que piensan que estoy "criticando" algo, o afirmando que la programación orientada a aspectos va a desaparecer. En un momento, la siguiente gran cosa fue la programación estructurada. La programación orientada a objetos surgió de eso, y ahora ya nadie habla de hacer "programación estructurada". Pero, de muchas maneras, todavía estamos utilizando sus mejores ideas, porque OOP las adoptó, las mejoró y agregó aún más ideas nuevas.
Voy a sugerir que no fue lo suficientemente grande. Suena muy atractivo, pero ¿realmente hace que la codificación sea más fácil? He estado queriendo probarlo y encontrar los beneficios que realmente tiene, pero no creo que haga suficiente codificación donde necesito las relaciones que proporciona. No creo que sea tan beneficioso como parece.
También en este punto, facilitar la programación de multinúcleo es algo muy importante y no creo que la programación orientada a aspectos ayude con eso.
También puede encontrar gran cantidad de contenido sobre Riesgos de Adopción .
A principios de los años 2000 ha habido mucha expectación, y lo que sucedió es lo siguiente: ha habido muchos intentos de crear marcos orientados a los aspectos, y estos intentos se han fusionado en dos proyectos importantes en la esfera de Java: AspectJ y Spring AOP. AspectJ es completo, complejo, académico, algo sobredimensionado. Spring AOP cubre el 80% de los casos de uso con un 20% de complejidad.
Si observa Google Trends para ver los términos "AspectJ, Spring AOP" , luego compare la popularidad de Java, verá que la popularidad relativa de AspectJ es algo constante, pero Spring AOP está aumentando. Eso significa que las personas usan AOP, pero no quieren la complejidad de AspectJ. Creo que los creadores de AspectJ cometieron muchos errores tácticos; AspectJ siempre ha sido un proyecto de investigación y no ha sido diseñado "para las masas".
En la esfera .NET, hemos visto un interés similar para AOP a principios de los 2000. En 2003, cuando comencé las investigaciones de AOP, había media docena de tejedores de AOP para .NET; todos seguían el camino de AspectJ, y todos estaban en etapa infantil. Ninguno de estos proyectos sobrevivió. Sobre la base de este análisis, construí PostSharp, que fue diseñado para cubrir el 80% de los casos de uso con un 20% de complejidad y, sin embargo, fue mucho más conveniente de usar que Spring AOP. PostSharp ahora se considera el tejedor de aspecto principal para .NET. PostSharp 2.0 se basa en 5 años de comentarios y de la experiencia de la industria de AspectJ y trae AOP "listo para la empresa" (futuro juzgará si este reclamo es merecido). Además de PostSharp, otros jugadores importantes son Spring Framework para .NET y Windsor Castle, dos marcos de aplicación centrados en DI que proporcionan aspectos ''también'' (los aspectos se consideran como dependencias inyectadas en objetos construidos). Dado que estas tecnologías utilizan el tiempo de ejecución, tienen limitaciones técnicas severas, por lo que prácticamente solo se pueden usar en objetos de servicio (para eso se diseñaron estos marcos de aplicaciones). Otro proyecto inicial en .NET es LinFu, que puede hacer aspectos ''también''.
Para ser breve, el panorama de AOP ha experimentado una cierta consolidación los últimos años, y probablemente entre en la fase de productividad: los clientes lo usarán porque realmente ahorra dinero, no porque sea genial. Incluso si es genial :).
Ah, y lo olvidé: la mayoría de los servidores de aplicaciones tienen soporte integrado para AOP. Pensando en JBoss, WebSphere y, hasta cierto punto, WCF.
Está disponible en algunos proyectos, mi propia experiencia en un proyecto reciente es demasiado fácil de abusar :(! Lo que comenzó como una buena manera de configurar la depuración, el tiempo y hasta cierto punto la administración de transacciones, se corrompió rápidamente a lo más extraño, y el código más difícil de entender y depurar que he visto en mucho tiempo.
solo para expandir un poco en el lado de depuración / diagnóstico, las trazas de pila generadas por el código AOP muchas veces ocultan más allá del reconocimiento el lugar real donde tuvo lugar la excepción.