Como la mayoría de los desarrolladores de aquí y en todo el mundo, he sido el desarrollo de sistemas de software utilizando programación orientada a objetos (OOP) técnicas para muchos años. Así que cuando leí que la programación orientada a aspectos (AOP) aborda muchos de los problemas tradicionales de la programación orientada a objetos no resuelve completamente o directamente, hago una pausa y pensar, ¿es real?

He leído un montón de información tratando de aprender las claves de este AOP y el paradigma de la mensajería instantánea en el mismo lugar, así que, quería entender mejor sus beneficios en el desarrollo de aplicaciones reales.

¿Alguien tiene la respuesta?

  • Todas las respuestas han sido muy buenas, este es un caso perfecto para una sola comunidad, editado respuesta que se combinan todos ellos. Todos están diciendo lo mismo pero en diferentes formas y mediante diferentes ejemplos que se suman a las que el valor total
InformationsquelleAutor yeradis | 2008-10-24

7 Comentarios

  1. 301

    Por qué «vs»? No es «vs». Puede utilizar la programación Orientada a Aspectos en combinación con la programación funcional, pero también en combinación con el Orientado a Objetos, uno. No es «vs», es el «Programación Orientada a Aspectos con Programación Orientada a Objetos».

    Me AOP es una especie de «meta-programación». Todo lo que AOP no podría también ser hecho sin ella con sólo añadir más código. AOP sólo le ahorra a escribir este código.

    Wikipedia tiene uno de los mejores ejemplos de este meta-programación. Supongamos que usted tiene una gráfica de clase con muchos «conjunto de…()» métodos. Después de cada método de juego, los datos de los gráficos cambiado, por lo tanto los gráficos cambiado y por lo tanto los gráficos deben ser actualizados en la pantalla. Asumir para volver a dibujar los gráficos que usted debe llamar «de Pantalla.update()». El enfoque clásico es resolver esto mediante la adición de más código. Al final de cada set método de escribir

    void set...(...) {
        :
        :
        Display.update();
    }
    

    Si usted tiene 3 métodos, que no es un problema. Si tienes 200 (hipotético), es realmente doloroso para agregar esta en todas partes. También cada vez que se agrega un nuevo método, usted debe asegurarse de no olvidar agregar esto al final, de lo contrario se acaba de crear un error.

    AOP resuelve esto sin la adición de toneladas de código, en lugar de agregar un aspecto:

    after() : set() {
       Display.update();
    }
    

    Y eso es todo! En lugar de escribir el código de actualización de sí mismo, que acaba de decirle al sistema que después de un set() pointcut ha sido alcanzado, se debe ejecutar este código y se ejecuta este código. No hay necesidad de actualizar 200 métodos, no hay necesidad de asegurarse de que usted no se olvide de agregar este código en un nuevo método. Además, sólo se necesita un pointcut:

    pointcut set() : execution(* set*(*) ) && this(MyGraphicsClass) && within(com.company.*);
    

    ¿Qué significa eso? Esto significa que si un método se denomina «conjunto*» ( * ) significa cualquier nombre puede seguir después de la puesta), independientemente de lo que el método devuelve (primer asterisco) o qué parámetros se lleva a una tercera (asterisco) y es un método de MyGraphicsClass y esta clase es parte del paquete «com.de la empresa.*», entonces este es un set() pointcut. Y nuestro primer código dice que «después de la ejecución de cualquier método que es un conjunto pointcut, ejecute el código siguiente».

    Ver cómo AOP elegantemente resuelve el problema aquí? En realidad todo lo que se describe aquí se puede hacer en tiempo de compilación. Un AOP preprocesador sólo puede modificar su código fuente (por ejemplo, la adición de la Pantalla.update() al final de cada set-pointcut método), incluso antes de la compilación de la misma clase.

    Sin embargo, este ejemplo también muestra una de las grandes desventajas de la AOP. AOP está haciendo algo que muchos programadores consideran un «Anti-Patrón«. El modelo exacto es el llamado «La acción a distancia«.

    La acción a distancia es un
    anti-patrón (un reconocido común
    de error) en el que el comportamiento en una parte
    de un programa varía enormemente basado en
    difícil o imposible identificar
    las operaciones en otra parte de la
    programa.

    Como un novato a un proyecto, podría leer el código de cualquier método y considero que es roto, como parece que no se actualice la pantalla. Yo no ver simplemente observando el código de un método, que después de que se ejecuta, algún otro código «mágicamente» se puede ejecutar para actualizar la pantalla. Considero que esto es un grave inconveniente! Mediante la modificación de un método, extraño los insectos podrían ser introducido. Aún más la comprensión del flujo de código de código donde ciertas cosas parecen funcionar correctamente, pero no son evidentes (como ya he dicho, sólo por arte de magia el trabajo… de alguna manera), es realmente difícil.

    Actualización

    Solo para aclarar que: Algunas personas pueden tener la impresión de que estoy diciendo la AOP es algo malo y no debe ser utilizado. Eso no es lo que estoy diciendo! AOP en realidad es una gran característica. Me acaba de decir «Utilizar con precaución». AOP sólo causará problemas si se mezcla normal de código y AOP para el mismo Aspecto. En el ejemplo anterior, tenemos el Aspecto de la actualización de los valores de un objeto gráfico y la pintura, el objeto actualizada. Que es de hecho un aspecto único. La codificación de la mitad de la normal de código y la otra mitad de la misma como aspecto es lo que añade el problema.

    Si el uso de AOP para una completamente diferente aspecto, por ejemplo, para el registro, usted no podrá ejecutar en el anti-patrón de problema. En ese caso de un novato en el proyecto podría preguntarse «¿a Dónde van todos estos mensajes de registro vienen? No veo ningún registro de salida en el código», pero que no es un gran problema. Los cambios que hace a la lógica del programa, apenas va a romper el registro de la instalación y de los cambios realizados en el registro de instalaciones difícilmente va a romper su programa de lógica de estos aspectos están totalmente separados. El uso de AOP para el registro tiene la ventaja de que el código del programa puede concentrarse en hacer lo que debe hacer y todavía puede tener registro sofisticados, sin tener su código está abarrotada por cientos de mensajes de registro en todas partes. También cuando el nuevo código se introduce, por arte de magia los mensajes de registro aparecerá en el momento adecuado con el contenido correcto. El programador novato podría no entender por qué están ahí o de dónde venían, pero desde que se registro de «lo correcto» en el «momento adecuado», sólo felizmente aceptar el hecho de que ellos están allí y pasar a otra cosa.

    Por lo que un buen uso de AOP en mi ejemplo sería para siempre de registro si cualquier valor ha sido actualizado a través de un método de juego. Esto no va a crear un anti-patrón y casi nunca la causa de cualquier problema.

    Uno podría decir, si usted puede abuso de AOP a crear muchos problemas, es una mala idea usar todos. Sin embargo, que la tecnología no puede ser objeto de abuso? Usted puede abusar de encapsulación de datos, se puede abusar de la herencia. Casi todos los útiles de programación de la tecnología puede ser objeto de abuso. Considere la posibilidad de un lenguaje de programación es tan limitada que sólo contiene características que no pueden ser objeto de abuso; un lenguaje en el que las características sólo puede ser utilizado como estaban inicialmente destinados a ser utilizados. Ese lenguaje sería tan limitado que es discutible si puede ser utilizado incluso para el mundo real de la programación.

    • El registro parece ser un ejemplo específico donde AOP no resultar en Acción a Distancia. En este momento, la wikipedia como ejemplo de la utilización de aspecto para cosas como los controles de seguridad, que son los que realmente hacen que el flujo de un programa que mucho más para entender.
    • Gran punto en el registro, de hecho, es el mejor ejemplo que he visto hasta ahora AOP de la fuerza, sin saber mucho acerca de AOP. Gracias por compartir!
    • Su ejemplo es excesivamente simplificado y no reflejar el general de casos de uso. En tu ejemplo, Display.update no lleva argumentos. Lo que si tenemos que pasar argumentos (por ejemplo, generalmente un log función requeriría un message parámetro)? No tenemos que agregar en un montón de código repetitivo para hacerlo de la AOP manera?
    • Mi ejemplo es simple porque no hay una enseñanza foro. Yo estaba contestando a la pregunta del interrogador, probablemente mucho más detallada que la que habría sido necesaria. Si usted quiere saber más acerca de la AOP, trate de leer algunos programador de la documentación y si usted tiene un detallado pregunta, ¿por qué no pedir aquí? No, no en un comentario, vaya y crear una nueva pregunta, porque que es lo que es todo acerca de. Estoy seguro de que alguien será capaz de disipar sus dudas en una respuesta.
    • Usted ha afirmado que el AOP no necesita «añadir un montón de código» y pasó a ilustrar esto con un ejemplo. Estoy diciendo que tu ejemplo es injusta, porque es demasiado simplificado (sin parámetros). En la mayoría de los casos, haciendo de la AOP-manera realmente requiere la adición de un montón de código repetitivo así.
    • Creo que simple mal entendido de mi ejemplo. No uso de AOP a hacer cosas como genérico de registro de cadenas de texto arbitrarias; que la utilice para el registro de las cosas como las llamadas a la función, tal vez incluyendo sus parámetros (o sólo si hay parámetros coinciden con determinados textos) y aquí escriben exactamente cero líneas de código repetitivo. Si desea utilizar AOP genéricos para el registro, usted está usando un patrón incorrecto de seguro y que me dice usted no ha entendido realmente lo AOP es todo acerca de.
    • Te he entendido mal mi ejemplo. El aspecto de los parámetros que estaba hablando se derivan de las funciones de los parámetros, y no son arbitrarias cadenas de texto. 2) En el ejemplo, los parámetros de la pointcut declaración se omiten porque su preocupación es excesivamente simplificada y por lo tanto no requiere de ellos. Furthurmore, su ejemplo se muestra exactamente un pointcut y un consejo para la preocupación. En casos reales, tendríamos que lidiar con múltiples pointcut declaraciones (cada una con su propio consejo) por la preocupación, y que incluso difieren en arity y la lista de parámetros.
    • Por lo tanto, mi comentario de que su ejemplo es excesivamente simplificado y no reflejar el general de casos de uso. En otras palabras, es una injusta ejemplo, mostrando AOP en una mejor luz, que lo que realmente es más realista.
    • Lo siento, pero no puedo ver su punto. Ver aquí: stackoverflow.com/a/8843713/15809 Este código registra todas las llamadas a todos los métodos públicos, incluyendo todos argumento del método de los tipos y valores. Escribe esta exactamente una vez y no es cero el código repetitivo añadido a cualquier método, es sólo el código que se muestra en la respuesta.
    • Gran explicación, estoy de acuerdo en que no ser capaz de ver lo que se ejecuta de inmediato en el código es un gran inconveniente. No es como un cristal transparente. Yo prefiero ver la Pantalla.update() en lugar de pensar algo así como: «la pantalla se actualiza pero, ¿dónde?». Si sé que es el uso de AOP, yo también podría necesitar para hacer el extra-trabajo de buscar en el código que estoy viendo es de ser avisado, ¿no es cierto? Creo que el IDE ayuda, pero aún creo que viendo la Pantalla.update() es mejor. Hay un patrón llamado método de Plantilla que podría resolver ese tipo de problemas, supongo, ¿no es cierto?
    • Acabo de pensar acerca de la mejor solución si no sabemos nada acerca de la AOP. En tu ejemplo, tal vez voy a crear un nuevo método en MyGraphicsClass. En el método, yo pase de un «conjunto» de la función como un parámetro, y agregar update() al final del método. Creo que toma prestado de programación Funcional, pero es una buena solución, de todos modos?

  2. 27

    La programación orientada a objetos y AOP no son mutuamente excluyentes.
    AOP puede ser una buena adición a la programación orientada a objetos.
    AOP es especialmente útil para añadir código estándar como el registro, el seguimiento del rendimiento, etc. a los métodos sin tener que llenar el código del método con este código estándar.

  3. 27

    orientada a aspectos pogramming proporciona una buena manera de implementar cuestiones transversales como la tala, la seguridad.
    Estos transversales inquietudes son piezas de la lógica que han de ser aplicados en muchos lugares, pero en realidad no tienen nada que ver con la lógica de negocio.

    Usted no debería ver AOP como un reemplazo de la programación orientada a objetos, más como un buen complemento, que
    hace el código más limpio, débilmente acoplados y centrado en la lógica de negocio.
    Así, mediante la aplicación de AOP usted gt 2 ventajas principales:

    1. La lógica de cada preocupación es que ahora en un solo lugar, en contraposición a estar dispersos por toda la base de código.

    2. clases son más limpios, ya que sólo contienen código para que su principal preocupación (o núcleo de la funcionalidad) y preocupaciones secundarias se han trasladado a los aspectos.

  4. 10

    Yo creo que no hay una respuesta general a esta pregunta, pero una cosa a destacar es, que AOP no reemplazar la programación orientada a objetos, pero añade ciertos descomposición de las características que la dirección de la llamada la tiranía de la dominante de la composición (Uno) (o inquietudes transversales).

    Que sin duda ayuda en determinados casos, como el tiempo que usted está en control de las herramientas y lenguajes a utilizar para un proyecto específico, sino que también añade un nuevo nivel de complejidad con respecto a la interacción de los aspectos y la necesidad de herramientas adicionales como el AJDT a entender el programa.

    Gregor Kiczales una vez dio una interesante charla introductoria sobre AOP en Google Tech Talks que me recomienda ver: Programación Orientada a aspectos: la radicalidad de la Investigación en la Modularidad.

  5. 8

    Primero de todos los AOP no va a reemplazar la programación orientada a objetos. AOP se extiende la programación orientada a objetos. Las ideas y prácticas de la programación orientada a objetos permanecer relevantes. Tener un buen diseño de objetos, probablemente hará que sea más fácil extenderla con aspectos.

    Yo creo que las ideas que AOP trae son importantes. Tenemos que buscar la manera de implementar transversales-preocupaciones sobre las diferentes clases en el programa sin tener que cambiar la duración de las clases. Pero creo que la AOP con el tiempo acaba de convertirse en parte de otras herramientas que uso y no una herramienta independiente o de la técnica. Ya vemos que esto ocurra.

    Un par de lenguajes dinámicos como Ruby y Python han construcciones del lenguaje como mixins que resolver los mismos problemas. Esto se parece mucho a AOP pero es mejor integrada en el lenguaje.

    La primavera y el Castillo y un par de inyección de dependencia marco tiene opciones para agregar comportamiento a las clases que se inyecte. Esta es una manera de hacer en tiempo de ejecución-tejido y yo creo que esto tiene mucho potencial.

    No creo que vas a tener que aprender un completamente nuevo paradigma para el uso de AOP. Las ideas son interesantes, pero poco a poco están siendo absorbidos por las herramientas existentes y de idiomas. Sólo manténgase informado y probar estas herramientas.

  6. 1

    Estoy tarde para anser esta pregunta, pero es uno de mis favoritos tema así que permítanme compartir mi punto de vista.

    OOP se utiliza principalmente para organizar tu lógica de negocio mientras AOP ayuda a organizar su no funcionales cosas como la Auditoría, Registro, Gestión de Transacciones , Seguridad, etc

    De esta manera se puede separar la lógica de negocios con la no-ficción lógica que hace el código más limpio.

    Nutria ventaja es que usted puede aplicar el consejo (por ejemplo en la auditoría) muy consistentemente sin implementar ninguna interfaz que le da una gran flexibilidad para su modificación sin tocar la lógica de negocio

Dejar respuesta

Please enter your comment!
Please enter your name here