VENTAJAS Y DESVENTAJAS
VENTAJAS
- Ayuda a superar los problemas causados por: Código Mezclado(Code Tangling) y Código Diseminado(Code Scattering)
Se entiende como Código Mezclado como en un mismo módulo de un sistema de software puedan simultáneamente convivir más de un requerimiento. Esta múltiple existencia de requerimientos lleva a la presencia conjunta de elementos de implementación de más de un requerimiento, resultando en un Código Mezclado.
El Código Diseminado se refiere a como los requerimientos están esparcidos sobre varios módulos, la implementación resultante también queda diseminada sobre esos módulos.
-
Implementación modularizada: POA logra separar cada concepto con mínimo acoplamiento, resultando en implementaciones modularizadas aún en la presencia de conceptos que se entrecruzan. Esto lleva a un código más limpio, menos duplicado, más fácil de entender y de mantener.
-
Mayor evolucionabilidad: La separación de conceptos permite agregar nuevos aspectos, modificar y / o remover aspectos existentes fácilmente.
-
Capacidad de retrasar las decisiones de diseño: para requerimientos actuales o que surjan en el futuro, permite, luego, implementarlos separadamente, e incluirlos automáticamente en el sistema.
-
Resuelve el dilema del arquitecto: ¿Cuántos recursos invertir en el diseño? ¿Cuándo es “demasiado diseño”?
-
Mayor reusabilidad: Al ser implementados separadamente, tiene mayor probabilidades de ser reusados en otros sistemas con requerimientos similares.
-
Divide y vencerás: Al separar la funcionalidad básica de los aspectos, se aplica con mayor intensidad el principio de dividir y conquistar.
-
Legibilidad: Al aislar y especificar requisitos no funcionales, mejora la legibilidad de la lógica central del negocio, permitiendo que los desarrolladores se concentren en la funcionalidad principal sin distracciones.
-
N-dimensiones: Ahora se tiene la posibilidad de implementar el sistema con las dimensiones que sean necesarias, no una única dimensión ”sobrecargada”.
-
Mínimo acoplamiento y máxima cohesión: Se genera una mejor implementación de un sistema si realizamos cada una de sus partes por separado y los unimos de una manera estrecha en donde estas partes, en este caso los aspectos interactúen adecuadamente.
DESVENTAJAS
-
Posibles choques entre el código funcional (expresado en el lenguaje componente) y el código de aspectos (expresados en los lenguajes de aspectos): Usualmente estos choques nacen de la necesidad de violar el encapsulamiento para implementar los diferentes aspectos, sabiendo de antemano el riesgo potencial que se corre al utilizar estas prácticas.
-
Posibles choques entre los aspectos: El ejemplo clásico es tener dos aspectos que trabajan perfectamente por separado pero al aplicarlos conjuntamente resultan en un comportamiento anormal.
- Problemas propios del desarrollo: Dado que, a la fecha, este es un paradigma particularmente nuevo, como con cualquier cosa, surgen problemas a medida que se desarrolla. Por esta misma razón, a medida que van surgiendo problemas, las tecnologías que implementan POA deben estar en constante y permanente actualización y cambio, lo cual genera problemas de compatibilidad con versiones diferentes en las que para solucionar algunos erores, se pierden características que antes si poseían.
- Posibles choques entre el código de aspectos y los mecanismos del lenguaje: Uno de los ejemplos más conocidos de este problema es la anomalía de herencia. Dentro del contexto de la POA, el término puede ser usado para indicar la dificultad de heredar el código de un aspecto en la presencia de herencia.
- Dificultades a la hora de hacer debugging: Debido a que en este paradigma se tiende a ocultar código buscando la modularización. En el caso de ocurrir un error en nuestra aplicación, puede que no sea fácil identificar si dicho error se originó en el código funcional o en algún aspecto, ya que el flujo real de la ejecución no es explícito y puede ser difícil de seguir.
- Fragilidad: Por la forma en que funcionan los pointcuts, cualquier cambio en un advice puede repercutir cambios y posibles errores en múltiples métodos de la aplicación. De la misma manera, cambiar el nombre de un método puede ocasionar que este deje de ser afectado por un advice o que empiece a ser manipulado por otro sin que nos percatemos. Esto exige tener un especial cuidado a la hora de crear y manipular métodos, lo que puede llegar a ser restrictivo.
- Portabilidad: AOP puede ser específico de un entorno particular, lo que limita la capacidad de reutilizar el código en diferentes plataformas, aplicaciones o lenguajes de programación.
- Documentación: Como se dijo anteriormente, se trata de un paradigma relativamente nuevo comparado con otros, esto causa que la documentación e implementaciones del mismo no tengan documentaciones robustas como, por ejemplo, la programación orientada a objetos. Esto puede suponer un problema para desarrolladores con poca experiencia o para proyectos de gran envergadura que deban depender en gran medida de este paradigma.
- Incremento de carga computacional: La definición de capas adicionales dentro del contexto de un proyecto y la inminente cantidad de puntos de comparación, evaluación de expresiones y en general, la inserción de código adicional en el flujo de ejecución de un programa, puede suponer un impacto significativo en el desempeño de la aplicación.
