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 is a well-structured Spring interface with clear purpose and documentation. The organization is logical: class-level Javadoc, then three method declarations in increasing specificity. Nesting is nonexistent, and each method has a single clear responsibility. The default methods provide sensible fallback behavior with excellent Javadoc explaining edge cases and usage guidance. The code length is appropriate—concise signatures with thorough documentation that justifies its presence. Action granularity is clean with one logical operation per line. Reading flow feels natural, following a progression from class-level candidate checks to method-level introspection. Minor deductions: Javadoc is somewhat verbose relative to the actual code, and the wildcard type argument `Class<?>` could be slightly more precise in modern Java, though this is standard Spring style. The nullable annotations add clarity. Overall, this represents exemplary interface design.
Run 3
The code is an interface with clear Javadoc, well-named methods, and logical organization. It has no deep nesting, and each method has a single clear purpose. The use of default methods for optional behavior is concise and maintains backward compatibility. Javadoc comments thoroughly explain intent, parameters, return values, and rationale, aiding readability. The code length is appropriate—no unnecessary verbosity. Reading flow is natural due to grouped methods and descriptive names. Minor deductions: reliance on external annotations and Javadoc depth might be slightly verbose for quick scanning, but this does not significantly impact readability.
Run 1
Code Structure: A cohesive interface logically groups candidate filtering, operation detection, and operation retrieval. Nesting: There is no nested control flow; default methods are flat and immediately understandable. Clarity of intent: Descriptive method names, explicit nullability annotations, and thorough Javadoc clearly communicate purpose and contracts. Code length: Implementation is concise, although documentation is somewhat verbose relative to the small interface. Action granularity: Each executable line performs a single clear action; the composed collection check remains easy to interpret. Reading flow: Methods progress naturally from class-level filtering to method-level detection and retrieval. Minor formatting limitations, such as missing blank lines between the package and import groups, slightly reduce visual polish.
Run 2
Code Structure: The interface logically groups candidate detection, operation checking, and operation retrieval. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive names, explicit nullability annotations, and thorough Javadoc clearly explain responsibilities and contracts. Code length: Implementation is concise; documentation is somewhat verbose but useful for an API. Action granularity: Each statement performs one focused action, and each method has a single responsibility. Reading flow: The progression from broad class filtering to method-level checking and retrieval is natural. Minor formatting issues, such as the lack of spacing between the package declaration and imports, slightly reduce readability.
Run 3
Code Structure: A small, logically organized interface separates candidate detection, operation existence checks, and operation retrieval. Nesting: Default methods are flat, with no branching or nested blocks. Clarity of intent: Descriptive method names, explicit nullability annotations, and detailed Javadoc clearly explain purpose and contracts. Code length: Executable code is minimal; documentation is somewhat verbose but useful for API consumers. Action granularity: Each implementation contains a single return statement, and each method has one clear responsibility. Reading flow: Methods progress naturally from class-level filtering to method-level checking and retrieval. Minor formatting limitations, such as tightly grouped imports and a long retrieval signature, slightly reduce visual readability.