It's not just a long name. The class makes sense in the context of this framework. The core problem (as others here point out) is that the Java flavor of OOP makes writing this sort of code idiomatic.
On the upside, you feel really smart once you grok all these concepts simultaneously. After a couple years this you get to brand yourself a "Java Architect".
Until, of course, you find you need to use it. Of course, you'll probably never need to use it, nor will you ever see it being used in your particular situation. But hey, it's all over-engineered nonsense, right?
This is a great comment. This is what a Java "Engineer" or "Architect" is supposed to understand. It is complex, but seems too abstracted from programming reality that it makes programming simple things more complicated then they have to be.
All of these things are useful and valid techniques for building scalable, maintainable and extensible code.
Abstract is a pretty basic OO concept. You make an abstract class when you want it to be derived and never used directly.
Singleton is where a class can only ever create one object. Harder than it sounds.
Proxy is where the class interfaces with something else. Again, very useful. Proxies are used by Spring to implement AOP.
Factory - abstracts away the creation of objects, in other words the client object does not need to know how to create objects. It's used extensively in the Spring IoC container.
Beans are object that use simple but powerful conventions of creating reusable components in Java.
Interceptors at used by AOP.
If you use these concepts as they are intended to be used then your code will be cleaner, maintainable and a joy to work with.
On the upside, you feel really smart once you grok all these concepts simultaneously. After a couple years this you get to brand yourself a "Java Architect".