That covers the basics of introduction creation. We will now discuss how you can use introductions
to solve the problem of object modification detection.
Object Modification Detection with Introductions
Object modification detection is a useful technique for many reasons. Typically you apply modification
detection to prevent unnecessary database access when you are persisting object data. If an object is
passed to a method for modification but it comes back unmodified, there is little point in issuing an
update statement to the database. Using a modification check in this way can really increase application
throughput, especially when the database is already under a substantial load or is located on some
remote network making communication an expensive operation.
Unfortunately, this kind of functionality is difficult to implement by hand because it requires you to
add to every method that can modify object state to check whether the object state is actually being
modified. When you consider all the null checks that have to be made and the checks to see whether the
value is actually changing, you are looking at around eight lines of code per method. You could refactor
this into a single method, but you still have to call this method every time you need to perform the
check. Spread this across a typical application with many different classes that require modification
checks, and you have a disaster waiting to happen.
This is clearly a place where introductions will help. We do not want to have to make it so each class
that requires modification checks inherits from some base implementation, losing its only chance for
inheritance as a result, nor do we really want to be adding checking code to each and every state-
changing method. Using introductions, we can provide a flexible solution to the modification detection
problem without having to write a bunch of repetitive, error-prone code.
In this example, we are going to build a full modification check framework using introductions. The
modification check logic is encapsulated by the IsModified interface, an implementation of which will be
introduced into the appropriate objects, along with interception logic to perform modification checks
automatically. For the purposes of this example, we use JavaBeans conventions, in that we consider a
modification to be any call to a setter method. Of course, we don't just treat all calls to a setter method as a
modification--we check to see whether the value being passed to the setter is different from the one
currently stored in the object. The only flaw with this solution is that setting an object back to its original
state will still reflect a modification if any one of the values on the object changed. For example, you have a
Contact object with the firstName attribute. Let's say that during processing the firstName attribute was
changed from Peter to John. As a result, the object was marked as modified. However, it will still be
marked as modified, even if the value is then changed back from John to its original value Peter in later
processing. One way to keep track of such changes is to store the full history of changes in the object's
entire life cycle. However, the implementation here is nontrivial and suffices for most requirements.
Implementing the more complete solution would result in an overly complex example.
The IsModified Interface
Central to the modification check solution is the IsModified interface, which our fictional application
uses to make intelligent decisions about object persistence. We do not look at how the application
would use IsModified; instead, we focus on the implementation of the introduction. Listing 7-6 shows
the IsModified interface.
Listing 7-6. The IsModified Interface
package com.apress.prospring3.ch7.introductions;
public interface IsModified {
public boolean isModified();
}
Search WWH :
Custom Search
Previous Page
Spring Framework 3 Topic Index
Next Page
Spring Framework 3 Bookmarks
Home