However, there’s a bit more to it than that. The methods I’ve been discussing so far are called primary methods. Primary methods, as their name suggests, are responsible for providing the primary implementation of a generic function. The standard method combination also supports three kinds of auxiliary methods: :before, :after, and :around methods. An auxiliary method definition is written with **DEFMETHOD** like a primary method but with a method qualifier, which names the type of method, between the name of the method and the parameter list. For instance, a :before method on withdraw that specializes the account parameter on the class bank-account would start like this:

Each kind of auxiliary method is combined into the effective method in a different way. All the applicable :before methods—not just the most specific—are run as part of the effective method. They run, as their name suggests, before the most specific primary method and are run in most-specific-first order. Thus, :before methods can be used to do any preparation needed to ensure that the primary method can run. For instance, you could’ve used a :before method specialized on checking-account to implement the overdraft protection on checking accounts like this:

(defmethod withdraw :before ((account checking-account) amount)
    (when (plusp overdraft)
      (incf (balance account) overdraft))))

The next advantage is that a primary method specialized on a class more specific than checking-account won’t interfere with this :before method, making it easier for an author of a subclass of checking-account to extend the behavior of withdraw while keeping part of the old behavior.

Lastly, since a :before method doesn’t have to call **CALL-NEXT-METHOD** to pass control to the remaining methods, it’s impossible to introduce a bug by forgetting to.

Finally, :around methods are combined much like primary methods except they’re run “around” all the other methods. That is, the code from the most specific :around method is run before anything else. Within the body of an :around method, **CALL-NEXT-METHOD** will lead to the code of the next most specific :around method or, in the least specific :around method, to the complex of :before, primary, and :after methods. Almost all :around methods will contain such a call to **CALL-NEXT-METHOD** because an :around method that doesn’t will completely hijack the implementation of the generic function from all the methods except for more-specific :around methods.

Occasionally that kind of hijacking is called for, but typically :around methods are used to establish some dynamic context in which the rest of the methods will run—to bind a dynamic variable, for example, or to establish an error handler (as I’ll discuss in Chapter 19). About the only time it’s appropriate for an :around method to not call **CALL-NEXT-METHOD** is when it returns a result cached from a previous call to **CALL-NEXT-METHOD**. At any rate, an method that doesn’t call **CALL-NEXT-METHOD** is responsible for correctly implementing the semantics of the generic function for all classes of arguments to which the method may apply, including future subclasses.