How would we prevent this? Asking for a friend.

Just refuse to play the insane Java/C# Enterprise OO game. Kotlin would be a good alternative but my preference would be Clojure where brevity and simplicity are valued.

Or just don't be redundant in any language. Unless there are multiple types of a "SerializationProvider", the name could be shortened to "ProtobufSerializationProvider"

And if there are multiple types of "SerializationProvider" (ie. there's an unrelated "CachingSerializationProvider ") then the name is unfortunately long, but accurate

I think the main problem is not in the name of that class, the name is just a side effect of a bigger deeper problem.

What problem? DI is really useful if you're pragmatic about it, misuse is not really a property of a particular language

It looks like they may have convention to put name of the base class/interface in the type name.

personally I find Java EE nauseating

Don't prevent them, encourage them.

The next guy who work on your code will be happy to have variable and class names longer than 3 characters. Short names are evil.

It's unfair to label this as "Enterprise OO Garbage".

It's simply a verbose name.

It is OO garbage. The giveaway is "Provider". The ball of mud that is OO inevitably necessitates enlisting an army of services, proxies, factories, builders and managers simply to work around the complexities of OO. Even if you have a simple problem OO tends to make it complex.

So how else do you implement that functionality, allowing you to choose the serialization protocol at runtime?

You need some data structure to combine the functionality for serializing and deserializing, and you then need some function that can, depending on context, choose the correct such data structure.

And now you've got your transportprotocolserializer, transportprotocolserializerprovider, and transportprotocolserializerproviderfactory

Even in Haskell or Scheme you'd end up with the same data structures and functions, one that does TransportProtocolEnum -> TransportProtocol, one TransportProtocol -> Data -> SerializedData, and one TransportProtocol -> SerializedData -> Data.

If you want to allow at runtime configuration of the transport protocol of each service, you still need the same structures and functions.

Or how else would you implement it?

Have an interface for Serializer, with N (> 1) implementations. Write the code to decide which to implementation to use in whatever place is appropriate for the desired functionality. For code that don't get to decide, pass the Serializer instance in.

You can interweave everything into one long function full of ifs and switches. E.g. procesurally. Not saying it is better.

> You can interweave everything into one long function full of ifs and switches. E.g. procesurally. Not saying it is better.

No, you cannot, since you want to dispatch to components that you don't even know of (pulled in via class path or extension DLLs). Components that have not yet been written and will be provided by another team or 3rd party and never compiled in, but just added to the extension directory of the application.

It's getting a bit tiring hearing cargo cult JS developers talk the talk, but walking backwards in their blissful stench of second level ignorance.

Verbose languages encourage a culture of verbosity which in turn produces verbose architecture.

What's wrong about it?

Are you sure this is not a German thing? /s

protokollprellbockverkehrprotokollserialisierunganbieter would be a lot catchier and roll off the tongue with ease.

let's see

   Protobuf-Transportprotokolserienvorrichter
   ProtopufSendeVorschriftLeitungsangebot
   VorlaufÜbertragungsDienstLeitungsDienstleister

what's wrong with pbtpsp anyway?

Pretty much everything? I hope you was just joking.

That made my day...

That doesn't seem like Enterprise OO bloat, just overly verbose naming.

They could've called it ProtobufSerializer or ProtobufProvider.

They tend to cluster together in my experience. That one was picked at random in the first file I looked at which implies there are much worse offenders in the rest of the codebase.