11.2. Pass the Buck
Tim and I implemented ZipCodeVerificationService for Sam using an third-party provider . After a little while, Sam came to me with a complaint.
"I'm spending way too much money utilizing that third party. I can't believe that it costs so much," he said.
I thought about comparing the amount he spent on the service to what he spent on his double latte each day. I quickly dismissed the idea.
"Can you log the requests to the service so that I can double-check that the number of lookups the service says it performed is equal to the number it actually performed?" he asked.
"Of course," I replied.
We do not want to alter the implementation that calls the service. It is time for the Proxy pattern , as described in Chapter 6. In the Proxy pattern, multiple classes implement the same interface. The methods in one proxy class perform some functionality, such as encryption or checking for security access violations. Then they call the corresponding method in another proxy class. Figure 11-1 shows the sequence of calls. The Proxy pattern allows you to preprocess, or postprocess, the functionality in the interface you are hiding behind the proxy. Since the proxy interface and the original interface are identical, the caller can be blind to which one is really being called.
Figure 11-1. Proxy pattern for ZipCodeVerificationService

Example 11-5 shows the ZipCodeVerificationServiceImplementation ...