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
The code is a Spring Framework interface with excellent readability. Javadoc comments thoroughly explain each method's purpose, parameters, return values, and edge cases. The structure is flat with no deep nesting, and method names like isCandidateClass, hasCacheOperations, and getCacheOperations clearly communicate intent. The default implementations are concise and use simple delegation, keeping action granularity to one or two operations per method. Reading flow is natural, moving from candidate class checks to method-level operations. Minor deductions for the verbosity of Javadoc (which is appropriate for framework APIs) and one multi-line return statement in hasCacheOperations, but overall this is highly readable framework code.
Run 3
This is a clean, well-structured interface definition. It clearly separates the three methods by purpose, with logical ordering and flat nesting. Javadoc is extensive and explains intent, including parameter contracts, nullability, and optimization hints. Method names are descriptive, and the single method with logic (hasCacheOperations) delegates concisely to getCacheOperations. The use of default methods keeps the interface lean while preserving flexibility. Formatting is consistent with Spring conventions, with proper spacing and import placement. Minor deductions: some Javadoc blocks are long and could feel verbose, and hasCacheOperations could optionally be simplified, but overall it is highly readable.
Run 1
Code Structure: A focused interface logically groups candidate detection, operation checking, and operation retrieval. Nesting: Minimal, with no nested control flow. Clarity of intent: Descriptive method names, explicit nullability annotations, and detailed documentation clearly explain purpose and contracts. Code length: Implementation is concise; documentation is somewhat verbose but provides useful API context. Action granularity: Each implementation contains a single clear return statement, with no bundled actions. Reading flow: Methods progress naturally from class-level filtering to method-level checking and retrieval. Minor drawbacks are tightly grouped imports and slightly repetitive documentation, but overall readability is excellent.
Run 2
Code Structure: A small, logically organized interface separates candidate filtering, operation detection, and operation retrieval. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive names, explicit nullability annotations, and detailed Javadoc clearly explain contracts and default behavior. Code length: Executable code is concise; documentation is somewhat verbose but useful for an API. Action granularity: Each implementation contains a single return statement, with no unrelated actions combined. Reading flow: Methods progress naturally from class-level filtering to method-level checks and retrieval. Minor formatting limitations include the lack of spacing between package and import declarations and the long retrieval signature.
Run 3
Code Structure: A well-organized interface groups related cache-introspection methods with consistent documentation. Nesting: Flat methods have no branching or nested control flow. Clarity of intent: Descriptive method names, explicit nullability, and detailed Javadoc clearly explain behavior and contracts. Code length: Executable code is minimal; documentation is somewhat verbose but useful for an API. Action granularity: Each implementation contains a single return statement, with no unrelated actions combined. Reading flow: Methods progress naturally from class-level candidacy to method-level checks and operation retrieval. Minor formatting drawbacks include missing blank lines between the package declaration and import groups and a long final method declaration.