There are various common good examples of aspects like logging, auditing, declarative transactions, security, caching, etc. The key unit of modularity in OOP is the class, whereas in AOP the unit of modularity is the aspect.
Aspect-oriented programming is a technique for building common, reusable routines that can be applied applicationwide. During development this facilitates separation of core application logic and common, repeatable tasks (input validation, logging, error handling, etc.).
Rest assured that OOP is alive and well, as is Aspect Oriented Programming, Functional Programming and Procedural Programming. One of the signs of maturity in an application developer is being able to recognize the strengths of each style and finding how to use them to provide solutions.
Aspect-Oriented Programming (AOP) complements OOP by providing another way of thinking about program structure. While OO decomposes applications into a hierarchy of objects, AOP decomposes programs into aspects or concerns.
One of the examples which was loaned straight from this Aspect Oriented Programming: Radical Research in Modularity, Youtube video was painting to a display. In the example you have a drawing program, which consists of points, shapes, etc and when changes to those objects occur you need to tell the display to update itself. Without handling it in an aspect you end up repeating yourself quite a bit.
AOP, as I've understood it, was created for not repeating yourself for cross cutting concerns which might not have anything to do with business logic. With aspects you can modularize these concerns to aspects. One of the examples was logging but there are bunch of different things you might end up repeating. It has been evolving since and it's not any more about aspect-oriented programming but there's also aspect-oriented modelling.
More information about aspect oriented programming can be found from these sources:
Security
Friendlier error msgs for asp.net webcontrols/webparts
Performance
Validation:
[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; }
Undo - I am calling a third-party assembly that supports undo operations. It requires callers to create an undo context, call some methods in the assembly, adn then destroy the undo context. Contexts can be nested. Also, if a context is created but left in an undesirable state that requires an app restart.
Normally to use undo I would write something like this
void foo()
{
int id = lib.create_undo_context();
try
{
lib.performsomeaction();
lib.performsomeaction();
lib.performsomeaction();
}
finally
{
lib.destroy_undo_context(id);
}
}
with PostSharp I define an attribute called [Undo] that creates the undo context when the method starts and destroys it when the method exits (even if an exception is thrown) - so the code looks like this
[Undo]
void foo()
{
lib.performsomeaction();
lib.performsomeaction();
lib.performsomeaction();
}
It's a little more complicated to implement this than I am showing because I have ensure that all undo contexts are cleaned up even in cases where there are nested Undo contexts - but you get the idea.
Another classic example (like logging) is caching. But other examples are more interesting.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With