For illustrative purposes we'll just look at the account as a whole (i.e., ignore the codes). For example, we could have a set of financial transactions like those shown in Table 1.

Our prior solution is nearly sufficient here - change CachedProductBalances to CachedAccountBalances and ProductBalanceMapKey to AccountBalanceMapKey. The key difference is that for account balances we need to be able to do more than simply turn criteria on and off (i.e., an inUse array on CachedAccountBalances isn't enough). Instead we need to be able to specify the criteria in more detail. For example, we want to be able to cache the balances for a specific account (Savings) or accounts (Savings and Checking), rather than be forced to cache balances for every single account, as would be the case if we reused our original solution for product balances. We may even want to cache them for specific ranges of criteria (e.g., fiscal period 1 through 2).

In Part 1 we introduced the inUse array to determine, when updating and retrieving cached balances, which criteria were applicable and to replace the unused criteria with a placeholder. In this case we need a more complex array that can handle the transformation and management of the criteria. However, we still want our CachedAccountBalances class to do this without becoming entangled in the specific criteria being used. We met this requirement by introducing something called a specification key - a key that specifies a set of criteria. In order to be able to talk about the other keys (such as the AccountBalanceMapKey) we identified these as access keys - keys used to access information. The specification key contained the specification for each criterion and could transform an access key for use with a particular collection of cached balances.

At this point we identified the cached balances candidate pattern. In this pattern, as shown in Figure 2, we have a CachedBalanceSet that contains a set of balance values (CachedBalance) associated with access keys (AccessKey) that are specified by a specification key (SpecificationKey). In order for the CachedBalanceSet to be able to work with the keys without knowledge of the details, AccessKey must support equals and SpecificationKey must support convert (taking an AccessKey and returning a converted one). In other words, AccessKey and SpecificationKey declare interfaces that at this stage in the definition of our candidate pattern would then be implemented by domain-specific subclasses (e.g., a SpecificationKey subclass that supports specifying financial account balances, and an AccessKey subclass that is used to manage the various account balance criteria such as fiscal period and account code).

At this point, our first thought was to tie the key pattern and the cached balance patterns together. However, we ultimately chose to separate them into two distinct patterns since we have found that it is easier to later combine patterns versus trying to split them apart. In fact it may turn out that one of our candidates is in fact a pattern while the other isn't (or isn't worth turning into one). In our case we kept them separate because the key pattern - allowing algorithms to work with criteria abstractly, and the cached balance pattern - maintaining balance information over a specified set of criteria, met clearly different objectives and requirements.

Focusing on the key pattern, we realized that while each key (access and specification) could be written for a particular use of the pattern, we could provide an implementation of the core part of the function. (Such an implementation is often called a mini-framework or framelet.) To do this we created a new abstraction. This new abstraction, called a keyable, allowed the key to work with its criteria generically, thus eliminating the need for domain-specific implementations of AccessKey and SpecificationKey. An AccessKey was made up of AccessKeyables and a SpecificationKey was made up of SpecificationKeyables.

Each keyable defined an abstraction that declared the methods used for AccessKey and SpecificationKey. For example, AccessKey supports equals by comparing the AccessKeyables in the same position by using their equal method. If every AccessKeyable is equal, then the entire AccessKey is equal. Specific AccessKeyable subclasses provided their own implementations of equals to support this algorithm. This change to our candidate pattern had a nice side effect - by transferring the domain-specific responsibility from the Key classes to the Keyable classes, we were able to create a group of generally reusable Keyable classes (e.g., DateKeyable, PeriodKeyable, StringKeyable) that could be assembled to meet many different domain requirements. However, this approach also led us into a trap that we'll discuss below.

In this particular case, we decided to provide a reusable implementation of the pattern. In doing so, we provided a family of keyable subclasses that handled the majority of the different types of criteria. This was both a good and a bad idea. It was a good idea because providing prebuilt, partial implementations helped to enforce consistency in the use of the pattern; it allowed all uses of the pattern to take advantage of performance improvements in the base implementation; and it made the pattern attractive - a lot of the work was done for you. It was a bad idea because we ended up capturing and documenting the implementation and not the pattern. This was a problem because it made it very difficult to adapt the pattern to new situations - instead of adapting the pattern to the problem, we ended up adapting the problem to the pattern. In our case we exacerbated the problem by naively documenting the implementation as if it were the pattern. Had we clearly separated the pattern and implementation from the beginning, it would have been much better.

Once we identified this pattern, we needed to go back and determine if we should update our implementation of the CachedProductBalances. The main thing to keep in mind is that it is not necessary to make this sort of update. Rework takes time, so assume you won't make the update and convince yourself you should. While there are many considerations when making this decision, we found that the key ones were:

Remember that a pattern may never be complete. It may continue to be refined as each new use is found. Even in our example, where we spent a lot of time refining, documenting, and implementing the pattern as part of the second use, we didn't identify everything. As we continued on the project, we not only found other similar uses, but also found new and unexpected places where the pattern could be used.

We discovered that in many of these new cases we didn't have to update the core pattern, but instead added implementation notes that addressed applying the pattern in these particular cases. However, keep in mind that the capture of workaday patterns doesn't require formal documentation. Document only as much as you have to. Document enough to ensure you don't lose what you've learned and enough to enable the intended pattern consumer to benefit from what you've learned. You can always formalize it later.

Summary

Now that we've refined and captured the pattern, next time we'll look at applying the key pattern and cached balances pattern (with others) to the construction of applications, components, and Web services.