AOP ... ¿Debo olvidar programación orientada a objetos?
https://stackoverflow.com/questions/1325385
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
He rozado la documentación en línea, leer la entrada de la wiki, los postes y los blogs, pero todavía estoy confundido.
- ¿Qué es, en pocas palabras, Programación Orientada a Aspectos ?
- ¿Es simplemente mejor entonces Programación Orientada a Objetos? Debería olvidar programación orientada a objetos?
- Si no es así, ¿cómo sé cuándo usar uno o el otro? ¿Cuáles son las principales diferencias entre los dos?
- ¿Puedo refact uno en el otro?
Siempre he sido un hombre OO y quiero saber si tengo que cometer traición.
En serio, estoy empezando un nuevo proyecto pronto y quiero tomar las decisiones correctas desde el principio.
Solución
Programación ¿Qué es, en pocas palabras, orientada a aspectos?
En pocas palabras, AOP es la capacidad de inyectar acciones en el flujo típico de otro programa, discretamente. Esto le permite capturar instancias de clase, las llamadas a métodos, tareas, etc.
¿Es simplemente mejor entonces programación orientada a objetos? Debería olvidar programación orientada a objetos?
No, y no. Se trabaja en conjunto con cualquier entorno de programación que lo soporta. (Ver arriba).
Si no es así, ¿cómo sé cuándo usar uno o el otro? ¿Cuáles son las principales diferencias entre los dos?
Se utiliza AOP, generalmente, cuando se desea implementar algún tipo de acciones en cientos de clases, sin manipular las clases mismas. Ejemplos típicos son la seguridad (autorización de la derecha para llamar al método / clase dada) o de registro. En mi experiencia, sin embargo, yo no lo uso para esto. (Yo no lo uso para nada, la verdad).
Como el anterior, la diferencia principal en realidad no existe, ya que no son comparables. Pero, supongamos que desea implementar el registro "normalmente", que acaba de llamar el registrador en los puntos apropiados:
log.write("hello");
Pero con AOP, es posible crear un 'aspecto' que se conecta a cada llamada de método, y log 'Método b llamada'. El punto es que en AOP se enfoque es más 'escopeta': se adjunta a todo, o sólo un pequeño subconjunto. Adición manual de registro es generalmente mejor.
¿Puedo refact uno en el otro?
No es realmente relevante, ver otras respuestas. De nuevo con seguridad, usted podría cambiar a un modelo de AOP de un modelo de programación orientada a objetos típicos this.IsAllowed () a algo como si (callingMethod.HasAttribute (foo)) {permitió = true; }
Hope esas respuestas son útiles. Déjeme saber si quieres que ampliar aún más.
Otros consejos
No, AOP complementa programación orientada a objetos, en lugar de suplantarlo. AOP y la programación orientada a objetos proporcionan diferentes tipos de "pegamento" para ayudar a combinar comportamientos. Programación orientada a objetos, por supuesto, le permite combinar comportamiento a través de la herencia y la composición, etc. AOP, por otro lado le permite agregar un comportamiento a la dirección preocupaciones transversales interceptando href="http://en.wikipedia.org/wiki/Pointcut" donde el nuevo código corre antes o después de los métodos elegidos de las clases escogidas.
Algunos ejemplos comunes de preocupaciones transversales son: seguridad, registro y control de transacciones. Un principio fundamental de un buen diseño es la coherencia: idealmente, una pieza de código debe hacer una sola cosa. Por lo que enturbia el agua para agregar código de seguridad para las clases de acceso de datos, por ejemplo. AOP resuelve ese problema particular, ya que permite agregar el comportamiento en un "aspecto" y luego aplicar ese aspecto a todas las clases que deben tener los controles de seguridad.
AOP es diferente a la programación orientada a objetos, completamente diferentes enfoques para el desarrollo.
Básicamente, si usted tiene la tala, las preocupaciones de autenticación, el código de comprobación de rendimiento, éstos serán los mismos, más o menos, en varias partes del programa, en diferentes clases. Por lo tanto, se puede escribir una aplicación que se le ha ocurrido que, en Java, a continuación, cuando es necesario agregar en estos otros tipos de código (entrecruzada), solo tienes que inyectarlos en el programa, de modo que puedan ser compilados en, pero cuando nos fijamos en el código fuente, que acaba de ver la lógica de negocio que necesita allí.
En cuanto a cuándo utilizar AOP o programación orientada a objetos, sugeriría que escribe el programa, que funcione, a continuación, cuando se tiene que funcionar, mirar a la eliminación de código que en realidad no tiene que ver con la función, sino que sirve algunos otro propósito. Por ejemplo, si es necesario comprobar que los parámetros de entrada son correctos antes de usarlos, a continuación, utilizar un aspecto de eso. Si usted tiene el control de eventos similares, como todas las excepciones producidas en la capa de acceso a datos escribe en un archivo de registro, a continuación, crear un aspecto para eso.
A medida que eliminar estos transversal se refiere el código se hacen más pequeños.
A medida que más experiencia verá más usos para AOP, pero al principio yo sugeriría escritura, entonces refactorizar usando AOP.
El uso de Eclipse, si se utiliza Java, por AOP, como el plugin AJDT será muy útil para ver donde está añadiendo aspectos.
Programación Orientada a Aspectos es una palabra de moda pegadizo para inserción de acciones (llamados "consejos") en los métodos o funciones en puntos clave como las llamadas y los rendimientos, entre otros. Tengo un gran problema con AOP porque viola todas las barreras de abstracción incorporadas en el lenguaje. No hay manera para un módulo de decir "esto es lo que un aspecto puede meterse con y esto es lo que un aspecto no puede meterse." Como resultado, se arriesga a que viola los invariantes internos, y se destruye el principio de razonamiento modular (que puede comprender un módulo sin tener que entender nada, pero las interfaces de los otros módulos que importa).
Hace algunos años Raimundito Stata escribió una tesis doctoral acerca de cómo brillante lenguajes orientados a objetos podrían controlar subclases y evitar que viola los invariantes clave. El trabajo correspondiente para AOP todavía no se ha escrito.
Mientras que con cualquier otra idea que gana la moneda, AOP ha disfrutado de algunos éxitos espectaculares (por ejemplo, instalación de registro a una aplicación que no está diseñado con el registro en mente), en general me le insto a confinar su uso AOP de los casos a muy simples . O mejor aún, sólo decir que no a la programación orientada a aspectos.
