Dig into the Code
To gain an understanding of the OOP design for the example requirement, refer to the source code download
and do the following:
- Start analyzing the EmployeeServiceTestCase code in the oldway package.
- Examine the testEmployeeCredit method.
- Look through the domain classes Employee and BusinessUnit.
- Learn the concepts behind service, repository, and factory. These are the artifacts used in a domain-driven design.
- Look at each of the service, repository, and factory classes at a higher level in the oldway package.
For AOP, follow these steps:
- Analyze the EmployeeServiceTestCase code in the newway package.
- Examine the service, repository, and factory classes. These classes will be more or less the same those of the previous one, except that you would let advices intercept the flow of the application.
- Study the aspect classes to learn the point cut definitions.
The following instructions walk you through executing the program:
- Download AspectWerkz 2.0.
- Set the following environment variables:
set JAVA_HOME=c:\Program Files\Java\jdk1.5.0
- Extract the source and other files to a folder.
- Compile the Java files, except the test case files. Otherwise, you will see an error during the weaving process.
- Perform offline weaving. Assuming you extracted the files to c:\aop and the class files are in c:\aop\classes, navigate to c:\aop and execute the following command:
%ASPECTWERKZ_HOME%\bin\aspectwerkz -offline etc/aop.xml -cp classes classes
- The AOP framework will modify the classes to inject the necessary byte codes.
- Compile the test case files and run them using JUnit text or GUI runner.
Once you have completed the preceding instructions, you should have a strong understanding of the following:
- Cross cutting concerns in an application
- The meaning of an aspect with respect to AOP
- How to use AOP to move the cross cutting concerns out of the domain layer in an application by using point cuts and advices
- The differences between the flow of program control within the classes when using OOP and AOP in a given scenario
Hopefully, you also gained a new perspective on real world programming from this article. You should feel confident in using AOP to improve the design, modularity, and reusability of the code in your projects. At the very least, you can start using AOP for the logging, error-handling, and persistence aspects of applications.
Personally, I find the learning curve for AOP steep. Specifically, understanding the syntax for defining point cuts is a chore. Ideally, you would use OOP to design domain models and use AOP to move the concerns that cut across the domain classes out, hence making them neat and readable.
Another downside of AOP is debugging can be difficult, becauseunlike OOPthe program flow is not straightforward and the interactions are determined only at compile time or at runtime. I'm counting on some intelligent tools to address this issue in the near future.