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
This is a very readable interface definition. The structure is logical, with clear method separation and well-organized Javadoc. Nesting is minimal. The intent of each method is immediately clear from names like isCandidateClass and getCacheOperations. Code length is appropriate—not unnecessarily verbose—and the Javadoc provides useful context without being excessive. Action granularity is clean, with simple return statements and no complex operations. Reading flow is natural, progressing from class-level candidate checks to method-level operation retrieval. The only minor deductions are for slightly dense Javadoc blocks on default methods, which could be slightly condensed, but overall this is exemplary code readability.
Run 2
The code demonstrates excellent readability through a clear interface contract, logical method ordering, and comprehensive Javadoc documentation. Structure is highly organized: one top-level interface with two default methods and one abstract method, each serving a distinct purpose. Nesting is completely flat, with no conditionals or loops. Intent is unambiguous—each method’s role (candidate check, presence check, retrieval) is well-defined and named descriptively. Code length is appropriate for an API contract; Javadoc adds necessary context without bloating logic. Action granularity is ideal, with single-purpose lines and simple return statements. Reading flow is natural: candidate detection, then presence check, then retrieval, mirroring a logical progression from broad to specific introspection. The only minor deduction is the slightly verbose Javadoc, but this is justified for a framework-level interface.
Run 3
This is a well-structured Spring interface. The code has a clear single responsibility: defining a contract for cache operation metadata. It uses flat nesting with only interface-level methods, each performing one logical action. The Javadoc is thorough and explains intent, preconditions, and return values clearly, including @since tags and nullability annotations. Method names are descriptive (e.g., isCandidateClass, hasCacheOperations). Default methods are concise and reusable. Reading flow is natural due to consistent ordering of documentation before each method and logical grouping of related operations. Minor deductions: the extensive Javadoc adds length, and the parameter name 'targetClass' repeats across methods, but this is standard for clarity. Overall, highly readable with no unnecessary complexity.
Run 1
Code Structure: A focused interface logically groups candidate detection, operation checking, and retrieval. Nesting: Flat method bodies contain no conditional or loop nesting. Clarity of intent: Descriptive names, explicit nullability annotations, and detailed Javadocs clearly explain the contract and default behavior. Code length: Executable code is concise; documentation is useful but somewhat verbose relative to the implementation. Action granularity: Each statement performs one clear action, with the composed emptiness check remaining easy to understand. Reading flow: Methods progress naturally from class-level screening to method-level checking and retrieval. Minor formatting limitations, such as missing spacing between package and import sections, slightly reduce visual readability.
Run 2
Code Structure: A focused interface with logically ordered candidate checking, operation checking, and operation retrieval. Nesting: Flat, with no nested control flow. Clarity of intent: Descriptive method names, explicit nullability annotations, and detailed Javadoc clearly communicate purpose and contracts. Code length: Implementation is minimal; documentation is somewhat verbose but provides useful API context. Action granularity: Each implementation contains a single return statement, with no unrelated actions combined. Reading flow: Consistent formatting and progression from broad class filtering to method-level retrieval make the code easy to follow. Minor readability drawbacks are the lack of spacing between import groups and the relatively long retrieval declaration.
Run 3
Code Structure: A well-organized interface groups three closely related cache-operation methods, with clear separation between declarations. Nesting: Default implementations are flat and contain no nested control flow. Clarity of intent: Descriptive method names, explicit nullability annotations, and thorough Javadoc clearly explain behavior and contracts. Code length: Executable code is minimal; documentation is somewhat lengthy but provides useful API context. Action granularity: Each implementation performs a single, focused action, with one return statement per line. Reading flow: The progression from class-level candidacy to method-level existence checks and operation retrieval is natural. Minor formatting improvements, such as separating the package declaration and import groups with blank lines, would improve scanning.