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 is(Class<?> target) {
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 has(Method met, @Nullable Class<?> target2) {
return !CollectionUtils.isEmpty(get(met, target2));
}
/**
* 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> get(Method met2, @Nullable Class<?> target3);
}
Run 1
The code is a well-structured Spring interface with clear Javadoc. It maintains a flat structure with no deep nesting, and each method serves a clear purpose: is(), has(), and get() for cache operation detection. The naming is mostly consistent, though the parameter names 'target', 'target2', 'target3', 'met', and 'met2' introduce slight ambiguity compared to the documented parameters 'targetClass' and 'method'. The default methods are concise, and action granularity is appropriate. Reading flow is natural, with documentation preceding each method. Minor readability deduction comes from the inconsistent parameter naming, which could confuse a reader attempting to trace the flow from documentation to implementation, and the somewhat terse method names like 'is' and 'has' which rely heavily on documentation to convey intent.
Run 2
The code is well-structured and readable as a Spring interface. It has clear separation of methods, good Javadoc documentation, and flat nesting with no complex logic. Intent is explicit through method names and documentation. However, parameter names like 'met', 'met2', 'target2', and 'target3' are unnecessarily abbreviated and inconsistent, which slightly reduces clarity. The method names 'is' and 'has' are also very generic without context. Default method bodies are appropriately concise. Overall, the code is maintainable and clear but could benefit from more descriptive parameter naming.
Run 3
The code is highly readable due to its clear logical structure as an interface with well-documented default methods. Nesting is minimal, with no deep blocks. Intent is explicit through descriptive method names and comprehensive Javadoc explaining purpose, parameters, and return values. Code length is concise, containing only necessary methods and defaults. Action granularity shows one action per line in method bodies. Reading flow is natural, progressing logically from class-level checks to method-level checks to retrieving operations. Minor deductions: parameter names like 'target2', 'target3', 'met', and 'met2' are slightly awkward and could be more descriptive, and the default method 'is' name is a bit terse. Overall, it adheres well to Spring's documentation standards and maintains excellent clarity.
Run 1
Code Structure: The interface is logically organized into three related operations, although imports lack visual separation. Nesting: Flat methods with no nested control flow are easy to follow. Clarity of intent: Documentation explains the caching contract, but vague method names (is, has, get) and inconsistent parameter names (met, met2, target2, target3) obscure meaning. Javadoc parameter names and method references do not match the declarations, creating confusion. Code length: Implementations are concise; extensive documentation is mostly useful but disproportionate to the small interface. Action granularity: Each method performs a single operation, with no crowded multi-action lines. Reading flow: The progression from class eligibility to operation existence to retrieval is natural, but naming inconsistencies and stale documentation interrupt comprehension.
Run 2
Code Structure: The interface is logically organized, with two default helpers followed by the core operation lookup declaration. Nesting: There is no nested control flow, making implementation easy to scan. Clarity of intent: Documentation explains the caching contract, but vague method names (is, has, get) and parameter names (met, met2, target2, target3) obscure meaning. Javadoc parameter names do not match actual signatures, and references to getCacheOperations and hasCacheOperations do not match declared methods. Code length: Implementations are concise; extensive documentation is mostly useful but disproportionate to the small interface. Action granularity: Each implementation contains a single, clearly separated return action. Reading flow: Declaration order is natural, but missing spacing around imports and inconsistencies between documentation and signatures interrupt an otherwise straightforward reading experience.
Run 3
Code Structure: The interface is logically organized into candidate detection, operation checking, and retrieval. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Detailed documentation explains the caching contract, but generic names such as is, has, and get, and parameters met2 and target3 obscure meaning. Documentation references and @param names do not match the actual declarations, creating confusion. Code length: Implementation is concise; documentation is lengthy but mostly useful. Action granularity: Each method performs a single action, and statements are clearly separated. Reading flow: The method order is natural, but mismatched documentation and missing spacing between package and import sections weaken an otherwise straightforward presentation.