I'm stumped as to why adoption of AO has been so slow. There are plenty of rich implementations out there for the predominant languages. My guess is that, like OO in it's day, it is enough of a paradigm shift that people don't recognize the places where it could be helping them.
So, beyond non-invasive logging, what are some of the ways that you have used, or plan to use AO, that reduces complexity, improves maintenance, enhances system "ilities"?
I am currently using AOP via EntLib / Unity in production for:
logging
caching
security
exception reporting
performance counters
Take a look at http://www.agileatwork.com/unit-of-work-with-unity-and-aspnet-mvc/ for an implementation of the unit of work pattern with AOP
[UnitOfWork]
public void Process(Job job)
{
...
}
Transaction management. I know it's a canonical use of AOP, but it really does shine when used for that.
And while I haven't had an opportunity to use it in a real-world situation, I see "around-advice" as being INCREDIBLY powerful, in particular for the value it adds to simplify the complexity of code by removing the need for many checks for rare conditions.
I agree for Spring AOP.
AOSD (we no longer speak about AOP I don't exactly why) is really useful for middleware/service oriented architecture where you already have, by design, some modularity.
I've used it in this context for telephony services with some really limited billing service.
I've also used it to build a kind of modular interpreter/compiler in order to perform some analysis around some code.
To my mind, one problem are the pointcut languages that could be sometimes tricky to describe exactly where you want to apply your advice. Another problem is composition, I don't know if it's been solved but it could be difficult to understand when you order your advices....
AOP is common, except people rarely call it AOP. Look at all the places in .NET programming where attributes are used. Attributes are essentially cross-cutting behaviors that can apply across many classes/methods/parameters.
More recently, the ASP.NET MVC platform has adopted heavy use of attributes, for a wide range of cross-cutting components such as security, data binding, and exception handling.
In my experience, with Spring AOP seems to be pretty common.
I think the difficulty is that people are just not used to thinking in terms of aspects, and weaving code in, even at compile time, can be somewhat scary, as it is harder to see what is actually affecting each method, for example, esp if you use a mixture of weaving at compile-time and run-time.
I have used it in situations where I have one controller, and I add in whether it is a servlet or webservice, for example. I have also used it to abstract out the database, so the database connections and database-optimized queries, could be woven into the application.
The e hardware verification language uses AOP.
Related
I understand the pros and cons of using object oriented programming as a concept. What I'm looking for are the pros and cons of using oo in progress/openedge specifically. Are there challenges that I need to take into account? Are there parts of the language that don't mesh well with oo? Stuff like that.
Edit: using 10.2b
I'll give you my opinion, but be forewarned that I'm probably the biggest Progress hater out there. ;) That said, I have written several medium-sized projects in OOABL so I have some experience in the area. These are some things I wrote, just so you know I'm not talking out of my hat:
STOMP protocol framework for clients and servers
a simple ORM mimicking ActiveRecord
an ABL compiler interface for the organization I was at (backend and frontend)
a library for building up Excel and Word documents (serializing them using the MS Office 2003 XML schemas; none of that silly COM stuff)
an email client that could send emails using multiple strategies
OOABL Pros:
If you absolutely must write Progress code, it is a great option for creating reusable code.
Great way to clean up an existing procedural codebase
OOABL Cons:
Class hierarchies are limited; you can’t create inherited (sub-)
interfaces in 10.2B (I think this was going to be added in 11). Older
versions of OpenEdge have other limitations like lack of abstract
classes. This limits your ability to create clean OO design and will
hurt you when you start building non-trivial things.
Error handling sucks - CATCH/THROW doesn’t let you throw your custom
errors and force callers to catch them. Backwards compatibility
prevents this from evolving further so I doubt it will ever improve.
Object memory footprint is large, and there are no AVM debugging
tools to track down why (gotta love these closed systems!)
Garbage collection wasn’t existent ‘til 10.2A, and still
has some bugs even in 11 (see official OE forum for some examples)
Network programming (with sockets) is a PITA - you have to run a
separate persistent procedure to manage the socket. I think evented
programming in OOABL was a PITA in general; I remember getting a lot
of errors about “windowed environments” or something to that effect
when trying to use them. PUBLISH/SUBSCRIBE didn’t work either,
if memory serves.
Depending on your environment, code reviews may be difficult as most
Progress developers don’t do OOABL so may not understand your code
If above point is true, you may face active resistance from
entrenched developers who feel threatened by having to learn new
things
OO is all about building small, reusable pieces that can be combined to make a greater whole. A big problem with OOABL is that the “ABL” part drags you down with its coarse data structures and lack of enumerators, which prevent you from really being able to build truly beautiful things with it. Unfortunately, since it is a closed language you can’t just sidestep the hand you’re dealt and create your own new data or control structures for it externally.
Now, it is theoretically possible to try and build some of these things using MEMPTRs, fixed arrays (EXTENT), and maybe WORK-TABLEs. However, I had attempted this in 10.1C and the design fell apart due to the lack of interface inheritance and abstract classes, and as I expected, performance was quite bad. The latter part may just be due to my poor ability, but I suspect it's an implementation limitation that would be nigh impossible to surmount.
The bottom line is use OOABL if you absolutely must be coding in OpenEdge - it’s better than procedural ABL and the rough edges get slightly smoother after each iterative release of OpenEdge. However, it will never be a beautiful language (OO or otherwise).
If you want to learn proper object-oriented programming and aren’t constricted to ABL, I would highly recommend looking at a language that treats objects as a first-class citizen such as Ruby or Smalltalk.
In the last four years I have worked 80% of the time with OOABL (started with 10.1c).
I definitely recommend using OOABL but I think it is very important to consider that using OOABL the same way as in other OO languages is fraught with problems.
With "the same way" I mean design patterns and implementation practices that are common in the oo world. Also some types of applications, especially in the area of technical frameworks are hard to do with OpenEdge (e.g. ORM).
The causes are performance problems with OOABL and missing OO features in the language.
If you are programming in C# or Java for exampe, memory footprint and instantiation time of objects are not a big issue in many cases. Using ABL this becomes a big issue much more often.
This leads to other design decisions and prevents the implementation of some patterns and frameworks.
Some missing or bad OO features:
No class library, no data structures needed for oo
No package visibility as in java (internal in c#)
This becomes relevant especially in larger applications
No Generics
Really terrible Exception Handling
Very limited reflection capabilities (improved in oe11)
So if you are familiar with oo programming in other languages and start working with OOABL, you could reach a point at which you were missing a lot of things you expect to be there, and get frustrated when trying to implement such things in ABL.
If your application has to run on Windows only, it is also possible to implement new oo code in C# and call it from your existing progress code via clr bridge, which works very smoothly.
K+
Only one thing - "Error handling sucks" - it sucks, but not because you can not make your own error-classes a catch them in caller block - that works, I'm using that. What sucks is that mix from old NO-ERROR / ERROR-HANDLE option and Progress.Lang.Error / CATCH block and ROUTINE-LEVEL ON ERROR UNDO, THROW. That is a big problem, when exists no convention in team, which errorhandling and how will be used.
Aspect-oriented programming is a subject matter that has been very difficult for me to find any good information on. My old Software Engineering textbook only mentions it briefly (and vaguely), and the wikipedia and various other tutorials/articles I've been able to find on it give ultra-academic, highly-abstracted definitions of just what it is, how to use it, and when to use it. Definitions I just don't seem to understand.
My (very poor) understanding of AOP is that there are many aspects of producing a high-quality software system that don't fit neatly into a nice little cohesive package. Some classes, such as Loggers, Validators, DatabaseQueries, etc., will be used all over your codebase and thus will be highly-coupled. My (again, very poor) understanding of AOP is that it is concerned with the best practices of how to handle these types of "universally-coupled" packages.
Question : Is this true, or am I totally off? If I'm completely wrong, can someone please give a concise, laymen explanation for what AOP is, an example of a so-called aspect, and perhaps even provide a simple code example?
Separation of Concerns is a fundamental principle in software development, there is a classic paper by David Parnas On the Criteria To Be Used in Decomposing Systems into Modules that may introduce you to the subject and also read Uncle Bob's SOLID Principles.
But then there are Cross Cutting concerns that might be included in many use cases like authentication, authorization, validation, logging, transaction handling, exception handling, caching, etc that spawn all the layers in software. And if you want to tackle the problem without duplication and employing the DRY principle, you must handle it in a sophisticated way.
You must use declarative programming, that simply in .net could be annotating a method or a property by an attribute and what happened later is changing the behavior of code in runtime depending of those annotations.
You can find a nice chapter on this topic in Sommerville's Software engineering book
Useful links
C2 wiki CrossCuttingConcern, MSDN, How to Address Crosscutting Concerns in Aspect Oriented Software Development
AOP is a technique where we extract and remove the cross cutting concerns (logging, Exception handling, ....) from our code into it’s own aspect. leaving our original code focusing only on the business logic. not only this makes our code more readable, maintainable but also the code is DRY.
This can be better explained by an example:
Aspect Oriented Programming (AOP) in the .net world using Castle Windsor
or
Aspect Oriented Programming (AOP) in the .net world using Unity
AOP is about crosscutting concerns i.e. things that you need to do throughout the whole application. For instance logging. Suppose you want to trace when you enter and exit a method. This is very easy with aspects. You basically specify a "handler" for an event, such as entering a method. If necessary you can also specify with "wildcards" which methods you are interested in and then it is just a matter of writing the handler code, that could for instance log some info.
Aspect Oriented Programming is basically for separating the cross-cutting concerns (Non-functional) and develop it as aspects, like, security, logging, monitor etc., kept it aside whenever you need in your application, you can use it as plug & play. Only benefit we can achieve is clean code ,less code and programmers can focus on business logic(core concerns) , so that better modularity and quality system can be developed.
I know this question has been asked before, but this was one and a half years ago, though I thought it might be the time for a re-questioning. I also recognized it might be seen as subjective, but I guess there are objective reasons for/against AOP.
I would be interested in who is using AOP in software development and also why or why not using it.
I see AOP as a very strong paradigm which can make a lot of development tasks easier. But when it comes to using AOP in real world projects I have made the experience that many decision makers are barely open to it. How did you manage to introduce AOP into your projects?
Previously asked question from August 2008: Do you use AOP (Aspect Oriented Programming) in production software?
Our managers listen to their architecture team.
We tell them that AOP is the only solution to implement cross-concern features:
at a reasonable cost in the first place
without messing with the functional code written by the development team
without ever forgetting (compared to manually adding a try-catch to thousands of methods), now and in the future
without having to train or control what the developers are doing (some are great, others are a real mess)
with a good maintainability
True, our project is 20 developers and lasted for several years, so there is a huge mass of code. It's the only solution.
I believe the key is to use it only for cross-cutting concerns.
If you can code it using regular code, do so. But if it is way too big, then AOP is attractive and justified. Failing to limit AOP would lead to hundred AOP little codes, that would be very hard to understand.
And yes, our software is production-software. Hundreds of clinics depend on it!
We don't use AOP 100% per se but yes we do use whenever we feel appropriate (mostly Spring AOP; that is so nicely integrated with Spring framework)
How did you manage to introduce AOP into your projects?
Well, separate out the cross cutting concerns eg. tracing method calls. In Spring AOP, you can define an aspect (a runtime behavior) which will get applied to a "hooked" section of code. With "hooked" I mean, you should be able to group all the methods where you need this behavior under one common umbrella. At runtime, this umbrella'ed code will get a new behaviour as defined by your aspect.
Spring AOP as Peakit said is easy to introduce if you are already using Spring framework in your project.
I first added AspectJ for our tools project that is only used internally and never released to customers. This helped both the development team and management to gain confidence on the tool and have a clear idea about what it can do for them.
What are the possible and critical disadvantages of Aspect-Oriented Programming?
For example: cryptic debugging for newbies (readability impact)
I think the biggest problem is that nobody knows how to define the semantics of an aspect, or how to declare join points non-procedurally.
If you can't define what an aspect does independently of the context in which it will be embedded, or define the effects that it has in such a way that it doesn't damage the context in which it is embedded, you (and tools) can't reason about what it does reliably. (You'll note the most common example of aspects is "logging", which is defined as "write some stuff to a log stream the application doesn't know anything about", because this is pretty safe). This violates David Parnas' key notion of information hiding. One of the worst examples of aspects that I see are ones that insert synchronization primitives into code; this effects the sequence of possible interactions that code can have. How can you possibly know this is safe (won't deadlock? won't livelock? won't fail to protect? is recoverable in the face of a thrown exception in a synchronization partner?) unless the application only does trivial things already.
Join points are now typically defined by providing some kind of identifier wildcarding (e.g, "put this aspect into any method named "DataBaseAccess*". For this to work, the folks writing the affected methods have to signal the intention for their code to be aspectized by naming their code in a funny way; that's hardly modular. Worse, why should the victim of an aspect even have to know that it exists? And consider what happens if you simply rename some methods; the aspect is no longer injected where it is needed, and your application breaks. What is needed are join point specifications which are intentional; somehow, the aspect has to know where it is needed without the programmers placing a neon sign at each usage point. (AspectJ has some control-flow related join points which seem a bit better in this regard).
So aspects are kind of interesting idea, but I think they are technologically immature. And that immaturity makes their usage fragile. And that's where the problem lies.
(I'm a big fan of automated software engineering tools [see my bio] just not this way).
Poor toolchain support - debuggers, profilers etc may not know about the AOP and so may work on code as if all the aspects had been replaced by procedural code
Code bloat - small source can lead to much larger object code as code is "weaved" throughout the code base
I think the biggest disadvantage is using AOP well. People use it in places where it doesn't make sense, for example, and will not use it where it does.
For example, a factory pattern is obviously something that AOP can do better, as DI can also do it well, but the observer pattern is simpler when using AOP, as is the strategy pattern.
It will be harder to unit test, esp if you do the weaving at runtime.
If weaving at runtime then you also take a performance hit.
Having a good way to model what is going on when mixing AOP with classes is a problem, as UML I don't think is a good model at that point.
Unless you are using Eclipse then tools do have problems, but, with Eclipse and AJDT AOP is much easier.
We still use junit and nunit for example, and so have to modify our code to allow unit tests to run, when using priviledged mode AOP could do better unit tests by testing private methods also, and we don't have to change our programs just to make them work with unit-testing. This is another example of not really understanding how AOP can be helpful, we are still chained in many ways to the past with unit-test frameworks and current design pattern implementations and don't see how AOP could help us do better coding.
Maintenance and Debugging. With aop, you suddenly have code that is being run at a given point ( method entry, exit, whatever ) but in just looking at the code, you have no clue that it's even getting called, especially if the aop configuration is in another file, like xml config. If the advice causes some changes, then while debugging an application, things may look strange with no explanation. This doesn't affect only newbies.
I would not call it a critical disadvantage, but the biggest problem I have seen is one of developer experience and ability to adapt. Not all developers yet understand the difference between declarative and imperative programming.
We make use of the policy injection application block in EntLib 4.1 pretty extensively as well as Unity for DI and it's just not something that sinks in quickly for some people. I find my self explaining over and over again to the same people why the application is not behaving in the way they expect. It generally starts off them explaining something and me saying "see that declaration above the method." :) Some people get it right away, love it and become extremely productive -- others struggle.
Learning curve is not unique to AOP, but it seems to have a higher learning curve that other things that your average developer encounters.
With regard to the maintenance/debugging argument, aspect-oriented programming tends to go hand-in-hand with all the other aspects of agile software-development practices.
These practices tend to remove debugging from the picture, replacing it with unit testing and test-driven development.
In addition, it may be much easier to maintain a small, clear code footprint with advice than a large, incomprehensible code footprint without advice (the advice being the thing that transforms a large, incomprehensible code footprint into a small, clear code footprint).
Because the power of AOP, if there is a bug your crosscutting, it can cause to widespread problems. On the otherhand, someone might change the join points in a program – e.g., by renaming or moving methods – in ways that the aspect writer did not expect, with unintended consequences. One advantage of modularizing crosscutting concerns is enabling one programmer to affect the entire system easily.
AOP is an interesting programming paradigm in my opinion. However, there haven't been discussions about it yet here on stackoverflow (at least I couldn't find them). What do you think about it in general? Do you use AOP in your projects? Or do you think it's rather a niche technology that won't be around for a long time or won't make it into the mainstream (like OOP did, at least in theory ;))?
If you do use AOP then please let us know which tools you use as well. Thanks!
Python supports AOP by letting you dynamically modify its classes at runtime (which in Python is typically called monkeypatching rather than AOP). Here are some of my AOP use cases:
I have a website in which every page is generated by a Python function. I'd like to take a class and make all of the webpages generated by that class password-protected. AOP comes to the rescue; before each function is called, I do the appropriate session checking and redirect if necessary.
I'd like to do some logging and profiling on a bunch of functions in my program during its actual usage. AOP lets me calculate timing and print data to log files without actually modifying any of these functions.
I have a module or class full of non-thread-safe functions and I find myself using it in some multi-threaded code. Some AOP adds locking around these function calls without having to go into the library and change anything.
This kind of thing doesn't come up very often, but whenever it does, monkeypatching is VERY useful. Python also has decorators which implement the Decorator design pattern (http://en.wikipedia.org/wiki/Decorator_pattern) to accomplish similar things.
Note that dynamically modifying classes can also let you work around bugs or add features to a third-party library without actually having to modify that library. I almost never need to do this, but the few times it's come up it's been incredibly useful.
Yes.
Orthogonal concerns, like security, are best done with AOP-style interception. Whether that is done automatically (through something like a dependency injection container) or manually is unimportant to the end goal.
One example: the "before/after" attributes in xUnit.net (an open source project I run) are a form of AOP-style method interception. You decorate your test methods with these attributes, and just before and after that test method runs, your code is called. It can be used for things like setting up a database and rolling back the results, changing the security context in which the test runs, etc.
Another example: the filter attributes in ASP.NET MVC also act like specialized AOP-style method interceptors. One, for instance, allows you to say how unhandled errors should be treated, if they happen in your action method.
Many dependency injection containers, including Castle Windsor and Unity, support this behavior either "in the box" or through the use of extensions.
I don't understand how one can handle cross-cutting concerns like logging, security, transaction management, exception-handling in a clean fashion without using AOP.
Anyone using the Spring framework (probably about 50% of Java enterprise developers) is using AOP whether they know it or not.
At Terracotta we use AOP and bytecode instrumentation pretty extensively to integrate with and instrument third-party software. For example, our Spring intergration is accomplished in large part by using aspectwerkz. In a nutshell, we need to intercept calls to Spring beans and bean factories at various points in order to cluster them.
So AOP can be useful for integrating with third party code that can't otherwise be modified. However, we've found there is a huge pitfall - if possible, only use the third party public API in your join points, otherwise you risk having your code broken by a change to some private method in the next minor release, and it becomes a maintenance nightmare.
AOP and transaction demarcation is a match made in heaven. We use Spring AOP #Transaction annotations, it makes for easier and more intuitive tx-demarcation than I've ever seen anywhere else.
We used aspectJ in one of my big projects for quite some time. The project was made up of several web services, each with several functions, which was the front end for a complicated document processing/querying system. Somewhere around 75k lines of code. We used aspects for two relatively minor pieces of functionality.
First was tracing application flow. We created an aspect that ran before and after each function call to print out "entered 'function'" and "exited 'function'". With the function selector thing (pointcut maybe? I don't remember the right name) we were able to use this as a debugging tool, selecting only functions that we wanted to trace at a given time. This was a really nice use for aspects in our project.
The second thing we did was application specific metrics. We put aspects around our web service methods to capture timing, object information, etc. and dump the results in a database. This was nice because we could capture this information, but still keep all of that capture code separate from the "real" code that did the work.
I've read about some nice solutions that aspects can bring to the table, but I'm still not convinced that they can really do anything that you couldn't do (maybe better) with "normal" technology. For example, I couldn't think of any major feature or functionality that any of our projects needed that couldn't be done just as easily without aspects - where I've found aspects useful are the kind of minor things that I've mentioned.
I use AOP heavily in my C# applications. I'm not a huge fan of having to use Attributes, so I used Castle DynamicProxy and Boo to apply aspects at runtime without polluting my code
We use AOP in our session facade to provide a consistent framework for our customers to customize our application. This allows us to expose a single point of customization without having to add manual hook support in for each method.
Additionally, AOP provides a single point of configuration for additional transaction setup and teardown, and the usual logging things. All told, much more maintainable than doing all of this by hand.
The main application I work on includes a script host. AOP allows the host to examine the properties of a script before deciding whether or not to load the script into the Application Domain. Since some of the scripts are quite cumbersome, this makes for much faster loading at run-time.
We also use and plan to use a significant number of attributes for things like compiler control, flow control and in-IDE debugging, which do not need to be part of the final distributed application.
We use PostSharp for our AOP solution. We have caching, error handling, and database retry aspects that we currently use and are in the process of making our security checks an Aspect.
Works great for us. Developers really do like the separation of concerns. The Architects really like having the platform level logic consolidated in one location.
The PostSharp library is a post compiler that does the injection of the code. It has a library of pre-defined intercepts that are brain dead easy to implement. It feels like wiring in event handlers.
Yes, we do use AOP in application programming . I preferably use AspectJ for integrating aop in my Spring applications. Have a look at this article for getting a broader prospective for the same.
http://codemodeweb.blogspot.in/2018/03/spring-aop-and-aspectj-framework.html