Creating Ad Hoc Taxonomies

Multimethods let you create ad hoc taxonomies, which can be helpful when you discover type relationships that are not explicitly declared as such.

For example, consider a financial application that deals with checking and savings accounts. Define a Clojure map for an account, using a tag to distinguish the two:

Now, you’re going to create two different checking accounts, tagged as ::checking and ::savings. The doubled :: causes the keywords to resolve in the current namespace. To see the namespace resolution happen, compare entering :checking and ::checking at the REPL:

Placing keywords in a namespace helps prevent name collisions with other people’s code. When you want to use ::savings or ::checking from another namespace, you’ll need to fully qualify them:

Full names get tedious quickly, so you can use alias to specify a shorter alias for a long namespace name:

Use alias to create the short name acc:

Now that the acc alias is available, create two top-level test objects, a savings account and a checking account:

Note that the trailing M creates a BigDecimal literal and does not mean you have millions of dollars.

The interest rate is 0% for checking accounts and 5% for savings accounts. Create a multimethod interest-rate that dispatches based on :tag, like so:

Check your test-savings and test-checking to make sure that interest-rate works as expected.

Accounts have an annual service charge, with rules as follows:

• Normal checking accounts incur a $25 fee.
• Normal savings accounts incur a $10 fee.
• Premium accounts have no fee.
• Checking accounts with a balance of $5,000 or more are premium.
• Savings accounts with a balance of $1,000 or more are premium.

In a realistic example, the rules would be more complex. Premium status would be driven by average balance over time, and there would probably be other ways to qualify. But the previous rules are complex enough to demonstrate the point.

You could implement service-charge with a bunch of conditional logic, but premium feels like a type, although there’s no explicit premium tag on an account. Create an account-level multimethod that returns ::premium or ::basic:

Test account-level to make sure that checking and savings accounts require different balance levels to reach ::premium status:

Now you might be tempted to implement service-charge using account-level as a dispatch function:

The conditional logic in service-charge for ::basic is exactly the kind of type-driven conditional that multimethods should help us avoid. The problem here is that you’re already dispatching by account-level, and now you need to be dispatching by :tag as well. No problem—you can dispatch on both. Write a service-charge whose dispatch function calls both account-level and :tag, returning the results in a vector:

This version of service-charge dispatches against two different taxonomies: the :tag intrinsic to an account and the externally defined account-level. Try a few accounts to verify that service-charge works as expected:

There’s one further improvement you can make to service-charge. Since all premium accounts have the same service charge, it seems redundant to have to define two separate service-charge methods for ::savings and ::checking accounts. It would be nice to have a parent type ::account so you could define a multimethod that matches ::premium for any kind of ::account. Clojure lets you define arbitrary parent-child relationships with derive:

Using derive, you can specify that both ::savings and ::checking are kinds of ::account:

When you start to use derive, isa? comes into its own. In addition to understanding Java inheritance, isa? knows all about derived relationships:

Now that Clojure knows that savings and checking are accounts, you can define a service-charge using a single method to handle ::premium:

At first glance, you may think that derive and isa? duplicate functionality that’s already available to Clojure via Java inheritance. This is not the case. Java inheritance relationships are forever fixed at the moment you define a class. derived relationships can be created when you need them and can be applied to existing objects without their knowledge or consent. So when you discover a useful relationship between existing objects, you can derive that relationship without touching the original objects’ source code and without creating tiresome “wrapper” classes.

If the number of different ways you might define a multimethod has your head spinning, don’t worry. In practice, most Clojure code uses multimethods sparingly. Let’s take a look at some open source Clojure code to get a better idea of how multimethods are used.