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 highly readable due to its clean interface design and excellent documentation. The structure is logical, with methods ordered by purpose and clear separation of concerns. Nesting is non-existent since this is an interface with default methods. Intent is extremely clear through comprehensive Javadoc explaining when and why each method should be used. Code length is appropriate - each method is concise despite extensive documentation. Action granularity is perfect, with single-purpose methods and one action per line. Reading flow follows a natural progression from class-level checks to method-level checks to operation retrieval. The only minor deduction is that the Javadoc is quite verbose, which could slightly slow reading, but this is justified for framework APIs.
Run 3
The code is a well-structured interface with clear separation of concerns. It uses Javadoc extensively, explaining purpose, parameters, return values, and since-tags, which greatly aids clarity. Nesting is non-existent, keeping the structure flat. Intent is unambiguous: the interface defines a contract for sourcing cache operation metadata. The code length is appropriate for a documented API, with no unnecessary complexity. Each method performs a single logical action, and the default implementations are concise. Reading flow is natural, from class-level candidate checks to method-level operation retrieval. The only minor deduction is that the verbose Javadoc might slightly reduce scannability for readers already familiar with the API.
Run 1
Code Structure: The interface is logically organized, progressing from class candidacy to operation existence and retrieval. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive names, explicit nullability annotations, and detailed Javadoc make the contract and default behavior clear. Code length: Implementation is minimal; documentation is somewhat verbose but useful for explaining introspection semantics. Action granularity: Each executable line performs a single focused action. Reading flow: Consistent formatting and method ordering support natural reading, though missing blank lines between package and import groups slightly reduce visual separation.
Run 2
Code Structure: A small, logically organized interface separates candidate filtering, operation detection, and operation retrieval. Nesting: The default methods are flat, with no nested control flow. Clarity of intent: Descriptive method names, nullable annotations, and thorough Javadoc make responsibilities and contracts clear. Code length: Executable code is concise; documentation is somewhat lengthy but explains important introspection behavior. Action granularity: Each default method contains a single return statement, and declarations remain distinct. Reading flow: Methods progress naturally from class-level filtering to method-level detection and retrieval. Minor readability drawbacks are the lack of spacing between package/import groups and the long final method declaration.
Run 3
Code Structure: The interface is logically organized, progressing from class candidacy to operation presence and retrieval. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive names, explicit nullability annotations, and thorough Javadoc clearly explain the contract and default behavior. Code length: Implementations are minimal; documentation is somewhat verbose but provides useful API context. Action granularity: Each implementation contains a single return statement, and declarations are cleanly separated. Reading flow: Consistent formatting and method ordering make the code easy to follow. Minor drawbacks are the lack of spacing between package and import groups and a long retrieval-method declaration.