I'm currently working on a project that i need to use Aspectj in it. In the documentation , for every aspect i wrote, i need to explain what were the reasons for using this aspect and not just write the code in the main program.
In generally, i only think about reasons like code-reusing, or flexibility (meaning the program can deal without this aspect, but the aspect will make the program more effective, like check things that maybe do some trouble in the future for example), but i think it is not enough.
While searching for more reasons, i saw that many programmers wrote "cross cutting" - what is the meaning of this and why its so important reason?
EDIT:
This question was asked during my school days, when aspects were something not so common in the projects. Now, 3 years after that, and a lot of backend programming in Java (Spring) I can answer to myself with simple example: the Repository aspect - This annotation(@repository) is used on Java classes which directly access the database.For example, when an exception occurs in the class there is a handler for that exception and there is no need to add a try catch block. It doesn't restrict to particular Class, doesn't care about the domain logic, it's to all of the Classes that want to interact with databases - this is a cross cutting problem.
Cross cutting, in my eyes, is mainly to have separation of concerns, i.e. you can separate the code that handles e.g. technical things (like e.g. logging, authorization, transactions etc.) from code that handles field of domain things.
But why and when is this useful?
It is especially useful if your development organisation also separates theses things, i.e. if some developers are responsible for field of domain programming and others for technical layers. So different persons can write their code in different places, not disturbing each other.
If the same persons write the different aspects it may still be useful to have this separation of concerns, but it is not that urgent in this case, at least not so urgent, that you want to mess with AspectJ, which introduces some additional complexity.