Sidebar
Table of Contents
Caching: Constant cache
Using inter-type declarations
Task: Pass tests.BoundsConstantCache.
Instead of making the (very) conservative approximation of getBounds() from the previous part, write an aspect instead that remembers the return value from the first time getBounds() has been called on a certain Group, and returns that first Rectangle for every subsequent call.
Group class to store the cache value.
A correct implementation should pass the tests of suite tests.BoundsConstantCache.
When done, remove the aspect from your build path before continuing with the next part.
Using several aspect instances
Imagine that a Group is serialized to some storage medium. If we use inter-type declarations to introduce a new field for the Group class, then this field will be included in the serialized data of a Group (so the schema changes). This is undesirable.
To avoid this, write a new version of the above aspect that does not change the fields of the Group class.
perthis instantiation strategy to have one aspect aspect instance for each advised Group object.
A correct implementation should also pass the tests of suite tests.BoundsConstantCache.
When done, remove the aspect from your build path before continuing with the next part.
Reusable caching aspect
A reusable caching aspect seems very useful. Create a generic caching aspect from your previous result by extracting at least:
- The type of the cache value: i.e.
Rectangleshould not be hardcoded, use a type variable instead - The operation being cached: i.e.
Group.getBounds()should not be hardcoded, make this pointcut abstract
Then reimplement your solution using this generic caching aspect. The new implementation should still pass the tests of suite tests.BoundsConstantCache.
Keep the last of your caching aspects active and continue with Exercise 3.
