Source code
package org.springframework.cache.interceptor;
import java.lang.reflect.Method;
import java.util.Collection;
import org.jspecify.annotations.Nullable;
import org.springframework.util.CollectionUtils;
/**
* Interface used by {@link CacheInterceptor}. Implementations know how to source
* cache operation attributes, whether from configuration, metadata attributes at
* source level, or elsewhere.
*
* @author Costin Leau
* @author Juergen Hoeller
* @since 3.1
*/
public interface CacheOperationSource {
/**
* Determine whether the given class is a candidate for cache operations
* in the metadata format of this {@code CacheOperationSource}.
* <p>If this method returns {@code false}, the methods on the given class
* will not get traversed for {@link #getCacheOperations} introspection.
* Returning {@code false} is therefore an optimization for non-affected
* classes, whereas {@code true} simply means that the class needs to get
* fully introspected for each method on the given class individually.
* @param targetClass the class to introspect
* @return {@code false} if the class is known to have no cache operation
* metadata at class or method level; {@code true} otherwise. The default
* implementation returns {@code true}, leading to regular introspection.
* @since 5.2
* @see #hasCacheOperations
*/
default boolean isCandidateClass(Class<?> targetClass) {
return true;
}
/**
* Determine whether there are cache operations for the given method.
* @param method the method to introspect
* @param targetClass the target class (can be {@code null},
* in which case the declaring class of the method must be used)
* @since 6.2
* @see #getCacheOperations
*/
default boolean hasCacheOperations(Method method, @Nullable Class<?> targetClass) {
return !CollectionUtils.isEmpty(getCacheOperations(method, targetClass));
}
/**
* Return the collection of cache operations for this method,
* or {@code null} if the method contains no <em>cacheable</em> annotations.
* @param method the method to introspect
* @param targetClass the target class (can be {@code null}, in which case
* the declaring class of the method must be used)
* @return all cache operations for this method, or {@code null} if none found
*/
@Nullable Collection<CacheOperation> getCacheOperations(Method method, @Nullable Class<?> targetClass);
}
Run 1
The code is highly readable. Structure is logical and interface methods are well-organized. Nesting is non-existent as it's an interface with flat default methods. Intent is crystal clear due to comprehensive Javadoc, good method naming, and clear use of @Nullable and @since annotations. Code length is concise—no unnecessary boilerplate. Action granularity is ideal: each default method has a single, clear action (returning a value or checking emptiness). Reading flow is natural, with methods ordered logically and documentation providing necessary context without redundancy. Minor deductions only because the extensive Javadoc, while beneficial, adds verbosity and the 'hasCacheOperations' method's inversion (checking emptiness) could be slightly more direct.
Run 2
This interface is highly readable. The package and imports are clean and minimal. The structure is logical, with clear separation of Javadoc and methods. Nesting is non-existent. Each method has a clear purpose, documented thoroughly. Code length is appropriate, and each method returns a simple, concise result. Action granularity is ideal; each method performs a single action. The reading flow follows a natural top-down progression: candidate class check, then cache operation check, then retrieval of operations. Javadoc explanations are detailed and helpful. Slight deductions for verbosity in documentation, which, while informative, extends the overall length, but the code itself remains clean and maintainable.
Run 3
The code is a well-structured Spring interface with clear separation of concerns. The Javadoc comments thoroughly explain the purpose and usage of each method, making the intent explicit. There is no deep nesting; each method is simple and delegates to helper utilities where needed. Action granularity is appropriate—each line performs a single logical step, such as checking collection emptiness. The reading flow is natural, following the conventions expected of Spring Framework code. The file is concise, with no unnecessary complexity. Minor deductions are for the length of Javadoc, which is typical in enterprise libraries but slightly slows initial reading for newcomers.
Run 1
Code Structure: The interface is logically organized, progressing from class-level eligibility to method-level checks and operation retrieval. Nesting: There is no nested control flow; default methods contain simple returns. Clarity of intent: Descriptive names, explicit types, nullability annotations, and thorough Javadoc make the contract clear. Code length: Executable code is concise, although the documentation is somewhat verbose relative to the small interface. Action granularity: Each statement performs one clear action; the composed emptiness check remains easy to understand. Reading flow: Consistent formatting and related method ordering support natural reading. Minor drawbacks are the lack of blank lines separating the package and import groups and slightly dense documentation.
Run 2
Code Structure: A focused interface logically groups candidate detection, operation existence checks, and operation retrieval. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive names, explicit nullable annotations, and detailed Javadoc clearly explain responsibilities and contracts. Code length: Implementation is minimal; documentation is somewhat lengthy but useful for API consumers. Action granularity: Each executable line performs one clear action. Reading flow: Methods progress naturally from broad class filtering to method-level checks and retrieval. Minor drawbacks include tightly grouped package/import declarations and a long final method signature, but neither substantially impairs readability.
Run 3
Code Structure: A small, logically organized interface separates candidate-class checking, operation existence checking, and operation retrieval. Nesting: Default methods are flat, with no nested control flow. Clarity of intent: Descriptive method names, explicit nullability annotations, and thorough Javadoc make the contract and optimization behavior clear. Code length: Implementation is minimal; documentation is somewhat verbose but mostly useful. Action granularity: Each default method contains a single return statement, with no unrelated actions combined. Reading flow: Methods progress naturally from broad class eligibility to method-level checking and retrieval. Minor readability drawbacks are the tightly packed package/import section and a long retrieval-method declaration.