Hello. This is lesson 3, aspect oriented programming. Here you'll be able to describe aspects, join points, point cuts, and weaving. You'll be able to configure advices via the AspectJ annotations. You'll be able to describe the difference between core concerns and cross-cutting concerns in an application. The goals of AOP are simple. Increase modularity by allowing the separation of cross-cutting concerns from the core concerns for your application. Let's define those. Core concerns are your business logic, calculations, getting data, presentation logic. Into weave with that logic will be cross-cutting concern logic. Logging, transaction management, security, it often clouds the code because so much code is taken up by doing these types of concerns. We want a way of applying these cross-cutting concerns not in a scattered form as they are at the moment, coded in multiple business means. But in the central place, we want the ability to apply these concerns or unwire those concerns. We may want to have logging, we may want to turn logging off, we may want to have security, we may want to have transactions, we may want to turn transactions off. Spring AOP is proxy-based. Basically a proxy looks and acts like the real thing, perform services on behalf of its client, delegates those to a target object or real object. It may add functionality prior to that delegation or after it comes back from that delegation. In some cases, the proxy may actually perform the service itself and not even delegate down. Security is an example of a blocking proxy. The proxy pattern therefore involves the creation of a stub or surrogate object. Proxy accepts invocations in the client and delegates to the real object, which does the business logic. The client thinks it's working with the real thing but it's not, it's working with the proxy. So how does it look like the real thing it would implement? For example, the same interface as the real thing, so it's going to have exactly the same API. AOP components, complements object-orientated programming in that there are distinct roles within the AOP framework, so to speak. There is an aspect or aspects where the cross-cutting concern logic will be found. It's actually found in methods that we call advices. There is a joint point which is basically where you can join into the application. In our case is method of execution. There's a pointcut which basically associates the joint point with an advice. Advice itself, which I mentioned which is where the actual cross-cutting concern code will be. There's something called weaving, which can be done at runtime or compile time. The compile time approach is done by a framework called AspectJ, where it will actually recompile the class to insert the code into the bytecode of the class itself. We do not do that, we use Spring AOP, which is proxy based at run-time. Aspects can be used as an alternative to existing technologies like Enterprise Java Beans for remote communication, transaction management, security profiling, and logging. Spring AOP is actually built on AOP interfaces called interceptors. Everything is Java, you do not need to learn a specialized language to do AOP. Objects created in the Spring IoC container, are unaware that they've been proxied and therefore advised. That proxying approach is dependent upon configurations. Spring AOP also has built-in aspects often called advisors for providing transaction management, performance monitoring, and security. Spring AOP is also based off a framework called AspectJ. Spring AOP, you could say is a subset of AspectJ, but AspectJ is compile-time weaving. It compiles a new class files and the advice is injected into the bytecode. Spring AOP is proxy-base. The proxy surrounds the whole invocation of the advice. Aspects can be defined using Spring configuration classes with key annotations. That's what we will follow. In order for this proxying mechanism to execute, you need an EnableAspectJAutorProxy on a Spring configuration class. In Spring Boot, you just need to add the Spring Boot starter AOP dependency in your maven palm. When the pin is created using reflection, the container says this class has a method that matches to a joinpoint that's associated with a pointcut that has an associated advice. Proxiate and the proxy will be responsible for executing that advice either before or after delegations to the real target object. Clients are unaware that the spring container has returned a proxy. Aspects. You need not aspect annotation. It must be spring managed. We then have a joinpoint. It is the expression you see here. This is saying, the joinpoint to the application is execution of the method work that takes zero to many arguments that can be any class in any package. We have a pointcut. The pointcut is basically a method, but it's really a label. The label here is log with the parentheses. Now we've added an advice, the app before annotation. You can see here, it's associating the advice with the pointcut log with the joinpoint. The advice is going to execute in this case before delegation down to the proxied object, the target, because it's an at before. What's actually happening is, the target pin is inflated by the container. As I've mentioned before, reflection says, you've got a work method. Zero to many arguments. Do I have a joint point for that? Yes, I do. It's associated with the point cut log, which is associated with the before advice. A proxy is generated and that proxy will delegate down to the logic and the aspect before it delegates down to the target bean. Now, we can get hold of some metadata by injecting in a joinpoint instance. The joinpoint instance gives us information about the joinpoint, such as what arguments were provided. It will also get what was the signature of the method that you are trying to get at. We frequently use this to log within our advices, the metadata from joinpoint. Now we can see, hey, there was a particular employee clocking in. Since we can get at the arguments, we can log that out. We cannot change the arguments in this type of advice. There are many different advices. The before advice we've seen, it'll execute before delegation to the target. The after advice would delegate after delegation to the target or if it throws an exception. So you could say this is like the finally equivalent in a try-catch block. The after returning advice, called after normal method execution without exception, and the after throwing advice is called after method execution, but it exits with an exception. I do not catch the exception, the exception will still be thrown up the execution stack, but I could change it to be a more generalized exception, and that's what I'm doing here. With the after returning, notice how I have two attributes in that annotation. Because we're returning normally, I can get it the return type. I'm returning foo here, so I look at my arguments to my method, that is my advice, I see a foo argument. I can get it that. I can't change it, but I can get it that. Because we now have more than one attribute, the default attribute pointcut, we now have to use an inexplicit format. Whereas you see with the after, there was only one attribute, so to speak, the default being pointcut, so I didn't have to say pointcut equals. We have a short lab to do with AOP now. You have instructions for it. Once you've completed the lab, I'll get back with you and we can walk through the solution. I'll see you on the other side.
