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.
Related
I was recently tasked with developing automated build and release pipelines for one of my company's legacy applications. After some investigation, I keep hearing from managers and other devs that certain application layers and architectures don't lend themselves to automation, particularly automated testing. Therefore, it's often suggested I shouldn't bother trying to apply DevOps principles and AT unless I want to re-architect the whole app.
The common cited example would be PL/SQL backends or monolithic architectures. I asked why these were not suitable, but never got a really clear answer. Does anyone have any insight on when automated test should not be used in favor of dumping the old architecture and starting fresh?
Short answer - ones that suffer from testability issues.
For a more in depth one, let's first admit that many software systems are untestable, or not immediately testable. So that, the effort of
trying to apply DevOps principles and AT
is far greater than the ROI. Such notorious example is Google's ReCAPTCHA, which causes some pain for the automation testing folks (like me). The devs are actually right to say that it will take be a
re-architect the whole app
journey, as testabilty is highly related to other key software qualities such as encapsulation, coupling, cohesion, and redundancy.
common cited example would be PL/SQL backends or monolithic architectures
Now, that is totally not the case. The firt one is more data-centric and requires a deeper understanding, but there are solutions to that as well. As to, single-tiered software applications - one can argue that in contrast to the mSOA, monolithic applications are much easier to debug and test. Since a monolithic app is a single indivisible unit, you can run end-to-end testing much faster/easier.
Put simply - if your app is highly testable, is highly usable. In case, the architecture and design were aligned to a very, very specific company needs - no wonder, is usable only up to a point.
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.
which technology to use for making a job hunting site
struts1,struts2,spring or simple servlet,jsp
which one runs faster as using a framework might slow you down.
struts1-> abstract class based -> so they should be faster than struts2 which are based on interfaces. (Anybody tested that if not how to test it.)
and about the spring i had no idea... it is said to be lightweight but what that terms actually means technically.
faster bean resolution or lesse libraries in which terms ...that "term lightweight" holds.
Use the one you are most familiar with. The technologies you mentioned are very generic/low-level, and not specific to a certain application such as a "job hunting website". The only slow-down you should worry about at this point is programmer productivity. If there really comes the time to do performance tuning later, this has probably nothing to do with how many bean classes and libraries need to be resolved, but with application (and database) design (on your end, not in the framework).
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.
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.