The names are extremely predictable (as shown by this Markov chain), which is actually a Good Thing (tm). The bad thing is that things got complex enough to war

The names are extremely predictable (as shown by this Markov chain), which is actually a Good Thing (tm). The bad thing is that things got complex enough to warrant these names. It's the knee jerk reflex of decoupling everything, to the point that you have 80% configuration/wiring/setup vs 20% of code that actually does something useful. Each extension point in the framework is represented by a couple of these classes to handle the layer of indirection. Maybe Spring should run a study and see which of their extension points is actually used, at all, or by more than x % of users, and then cut down all the useless ones. I'm not too familiar with Spring these days, but I'd expect that the vast majority of indirections isn't actually useful for anybody. The other problem is that our mechanisms to introduce and handle these abstractions are too verbose. Each extension point spawns multiple classes where it's really just one little method that needs to be called instead of another block of code. That makes software systems extremely hard to understand and use, and the overall bloat does actually slow things down - if not in production, then in deployment, startup, and build.