This chapter is from the book
This chapter is from the book
This chapter is from the book
2.10 Summary
We've come a long way in this chapter. We identified a problem in the Simple Insurance application that came to light when we decided to add support for pet insurance to the application, whereby calls to notifyListeners were spread throughout the policy class hierarchy. We decided to refactor this implementation to get back to a one-to-one mapping from design requirement (notify whenever the state of a policy object changes) to implementation. We applied the eXtreme programming philosophy "make sure everything is expressed once and only once," also known as the DRY principle (don't repeat yourself). Using AJDT and AspectJ, we were able to implement a modular solution to change notification using an aspect. The tools helped us during the refactoring process, both to explore the code and to incrementally test the changes we were making.
When we had finished, all the test cases were passing, we had replaced 15 calls to notifyListeners with one single call, found and removed a bug, and left behind a guard (the declare error) so that our chosen design modularity would remain in place in the code during evolution and maintenance. Even better, the solution we implemented in the aspect continued working even when the new PetPolicyImpl class was added—there was no additional effort spent implementing change notification for pet policies.
There is more that we could do to modularize change notification for policies— keeping track of listeners, and adding and removing them, also really belongs in the PolicyChangeNotification aspect. Chapter 8 shows you how to do that, too.
Footnotes
1. http://www.extremeprogramming.org/rules/refactor.html
2. This is just a conceptual model of how it works; the actual implementation as generated by the AspectJ compiler is much more efficient than this.