Using Interceptors in Spring for Business logic concerns

I am new to working with Spring on regular basis so I had a basic design question on it.

Should the concept of interceptors be used for separating out business logic in an application. E.g. A method getData is called from 3 classes/ One of the 3 needs some more processing before reaching the data. This processing is not a concern like logging etc which seems to be used more in examples for interceptors (I am basing this purely on my limited reading of Manning book), but a proper business logic of the app.

Should I be using interceptor here at all or normal if else or overriding should be used?

This has been my general curiosity to understand that whether interceptors only make sense for framework level concerns?

Since your custom logic execution would depend on the caller, not the called method, using an interceptor is indeed a strange choice.

Not knowing the details about your exact case, I'd suggest adding another method that executes the additional logic, and call it. In case you call 3 times the same method on the same interface but with 3 underlying implementations, just append the additional code in one of the underlying implementations.

Assuming this is for Spring MVC, interceptors are a quick and easy way to apply the same logic globally (or to a set of pages) without needing to mess around with individual controllers.

If you have 3 components which need to invoke the same method in a class, but one of these components needs the method to do something different, it sounds as if you should have different implementations of the class that provides the method. This way each component can just rely on the interface of the component which supplies getData(), and need not have any knowledge about how this method is implemented.