¿Alguien puede publicar un ejemplo de programación orientada a aspectos (AOP) que es no registrando?Ejemplos de programación orientada a aspectos
He examinado varios recursos pero todos los ejemplos son registros triviales. Para que sirve?
Uno de los ejemplos que fue cedido directamente desde este Aspect Oriented Programming: Radical Research in Modularity, Youtube video estaba pintando en una pantalla. En el ejemplo, tiene un programa de dibujo, que consiste en puntos, formas, etc. y cuando se producen cambios en esos objetos, debe indicarle a la pantalla que se actualice. Sin manejarlo en un aspecto, terminas repitiéndote un poco.
AOP, como lo he entendido, fue creado para no repetirse por cuestiones transversales que podrían no tener nada que ver con la lógica empresarial. Con los aspectos, puedes modularizar estas preocupaciones a los aspectos. Uno de los ejemplos fue el inicio de sesión, pero hay muchas cosas diferentes que podría terminar repitiendo. Ha estado evolucionando desde entonces y ya no se trata de programación orientada a aspectos, sino que también tiene modelos orientados a aspectos.
Más información acerca de la programación orientada a aspectos se puede encontrar a partir de estas fuentes:
Seguridad: comprobación de que los usuarios tienen los permisos adecuados antes de ejecutar ciertos métodos.
Verificación de invariante público. Dado que PostSharp 1.5 vendrá con herencia de aspecto, incluso a través de interfaces, dará muchas nuevas oportunidades.
Seguridad
más amigable Mensajes de error para WebControls ASP.NET/webparts
Rendimiento
Validación:
[NotNull]
public string Property1 { get; set; }
[Length(Min = 10, Max = 20)]
public string Property2 { get; set; }
[Regex(Expression = @"[abc]{2}")]
public string Property3 { get; set; }
¿Dónde está de Aspect? Pero puede utilizar algunos consejos para leer estas "anotaciones" que provienen de un punto de unión proporcionado por un punto como: * * guardar (..) Por lo tanto, puede utilizar un consejo para validar y proceder si es así o tirar condiciones de falla sobre el estado inválido. – paulosuzart
Depende de dónde se usa la validación y qué tipo de marco de interfaz de usuario se utiliza. No utilizo los aspectos en las entidades que necesitan ser validadas, sino más bien para la "codificación defensiva". No utilizo la validación de entidades en un método de guardado en un repositorio, pero valido en algún lugar en la UI. – Paco
@Paco, Esto no es realmente AOP; es más una programación anotada que un AOP. En AOP, no podemos especificar * cualquier cosa * en el sitio de la llamada. Incluso la existencia de '[NotNull]' no está permitida en AOP. – Pacerier
implementación de patrones de diseño en Java y AspectJ (Hannemann y Kiczales): http://www.cs.ubc.ca/labs/spl/papers/2002/oopsla02-patterns.pdf
El artículo muestra que algunos de los patrones de diseño GoF pueden aplicarse de mejor manera en Java utilizando AspectJ
No se puede tener la herencia múltiple en Java. Sin embargo, al usar AOP puede tener herencia múltiple "limitada". Intenta googlear esto para ver algunos ejemplos.
También estoy de acuerdo con Eyvid. El artículo de Hannemann y Kiczales es excelente para aprender los conceptos básicos sobre los patrones de diseño y obtener algunos excelentes ejemplos de AOP.
My photo album utiliza aspectj por tres cosas:
La primera, en particular, era más o menos directamente de una google tech talk on AOP. Se trata de la modularidad de una manera diferente a la que la mayoría de la gente considera. Definitivamente, recomiendo mirar eso si está interesado en cómo usarlo para siempre.
Otro ejemplo clásico (como el registro) es el almacenamiento en caché. Pero otros ejemplos son más interesantes.
Deshacer: llamo a un ensamblado de un tercero que admita operaciones de deshacer. Requiere que las personas que llaman creen un contexto de deshacer, invoquen algunos métodos en el ensamblado, y luego destruyan el contexto de deshacer. Los contextos se pueden anidar. Además, si se crea un contexto pero se deja en un estado no deseado que requiere un reinicio de la aplicación.
Normalmente al utilizar Deshacer me gustaría escribir algo como esto
void foo()
{
int id = lib.create_undo_context();
try
{
lib.performsomeaction();
lib.performsomeaction();
lib.performsomeaction();
}
finally
{
lib.destroy_undo_context(id);
}
}
con PostSharp defino un atributo llamado [Deshacer] que crea el contexto de deshacer cuando el método se inicia y se destruye cuando las salidas de método (incluso si se produce una excepción) - por lo que el código es el siguiente
[Undo]
void foo()
{
lib.performsomeaction();
lib.performsomeaction();
lib.performsomeaction();
}
es un poco más complicado de implementar esto que yo estoy mostrando porque he garantizar que todos deshacer contextos se limpian incluso en los casos en que se anidan en Deshacer contextos, pero tú captar la idea.
Gestión de transacciones.
En mi opinión, no desea que los objetos que pueden ser parte de una transacción sean conscientes de que están en una transacción. Con AOP, puede componer objetos en transacciones según sea necesario sin que los objetos de la transacción tengan que conocer el hecho de que están en una transacción o incluso de la existencia del marco AOP.
He utilizado la programación orientada a aspectos para implementar un motor de búsqueda de palabras clave. Fue más como un experimento, pero muestra cómo AOP se puede utilizar para otros fines que no sean el registro y el seguimiento.
Básicamente:
(i) El usuario de la máquina marca su/sus clases como KeywordSearchable,
(ii) El motor comienza a rastrear la creación & destrucción de estos casos KeywordSearchable,
(iii) Los extractos del motor las palabras clave de estos objetos KeywordSearchable,
(iv) Dados los objetos y las palabras clave, el algoritmo se encarga de la búsqueda.
Más detalles sobre esto se pueden encontrar en http://montrealistic.blogspot.com/2011/08/aspect-oriented-implementation-of.html.
inyección de dependencias
En sentido estricto, la inyección de dependencia es nada más que una preocupación transversal. Una gran cantidad de marcos de inyección de dependencia usar un estilo de programación basada en atributos como esto:
public class Car:IDisposable
{
[Inject]
public IGearBox Gearbox { get; set; }
...
}
El [Inyectar] atributo también podría diseñada como un aspecto sin ningún tipo de dependencia a un marco externo.
Ejemplos de AOP:
Imaginemos que desea registrar un mensaje dentro de los métodos de su modelo de dominio:
Ejemplo: Registro sin AOP:
namespace Examples\Forum\Domain\Model;
class Forum {
/**
* @Flow\Inject
* @var \Examples\Forum\Logger\ApplicationLoggerInterface
*/
protected $applicationLogger;
/**
* Delete a forum post and log operation
*
* @param \Examples\Forum\Domain\Model\Post $post
* @return void
*/
public function deletePost(Post $post) {
$this->applicationLogger->log('Removing post ' . $post->getTitle(), LOG_INFO);
$this->posts->remove($post);
}
}
Si usted tiene que hacer esto en muchos lugares, el registro se convertiría en parte de su lógica de modelo de dominio. Tendría que inyectar todas las dependencias de registro en sus modelos. Dado que el registro no es nada de lo que un modelo de dominio debería preocuparse, este es un ejemplo de un requisito no funcional y una llamada preocupación transversal.
Con AOP, el código dentro de su modelo no sabría nada sobre el registro. Simplemente se concentrará en la lógica de negocios.
AOP es propenso a errores porque no hay una localización de cambios. Básicamente son anotaciones sin la declaración de anotación (también conocidas como anotaciones invisibles). También vea https://pp.info.uni-karlsruhe.de/uploads/publikationen/constantinides04eiwas.pdf – Pacerier
@Pacerier: Su declaración es falsa. He estado usando AOP durante años para * evitar * errores y simplificar la refactorización y la depuración. Todo el código transversal que en OOP está enredado y disperso en toda la base del código está pulcramente modularizado y, por lo tanto, es fácil de localizar en AOP. El código central es fácil de leer y mantener. Las declaraciones como la suya se escuchan principalmente de personas que no han comprendido el concepto de AOP y no lo han usado extensamente (más allá de dar es un intento rápido, que simplemente no es suficiente). – kriegaex
@kriegaex, When Exactamente el concepto de AOP ha llegado. – Ali786