6 ms·
ProtobufTransportProtocolSerializationProvider Enterprise OO Garbage is alive and well.
by cutler 9y ago
ProtobufTransportProtocolSerializationProvider
Enterprise OO Garbage is alive and well.
- stephengillie 9y agoHow would we prevent this? Asking for a friend.
- cutler 9y agoJust 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.
- BoorishBears 9y agoOr 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
- smnplk 9y agoI think the main problem is not in the name of that class, the name is just a side effect of a bigger deeper problem.
- BoorishBears 9y agoWhat problem? DI is really useful if you're pragmatic about it, misuse is not really a property of a particular language
- 6ue7nNMEEbHcM 9y agoIt looks like they may have convention to put name of the base class/interface in the type name.
- solotronics 9y agopersonally I find Java EE nauseating
- user5994461 9y agoDon'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.
- tjohns 9y agoThat doesn't seem like Enterprise OO bloat, just overly verbose naming. They could've called it ProtobufSerializer or ProtobufProvider.
- cutler 9y agoThey 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.
- halfteatree 9y agoAre you sure this is not a German thing? /s
- justin66 9y agoprotokollprellbockverkehrprotokollserialisierunganbieter would be a lot catchier and roll off the tongue with ease.
- borplk 9y agoIt's unfair to label this as "Enterprise OO Garbage". It's simply a verbose name.
- cutler 9y agoVerbose languages encourage a culture of verbosity which in turn produces verbose architecture.
- 6ue7nNMEEbHcM 9y agoWhat's wrong about it?
- cutler 9y agoIt 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.
- kuschku 9y agoSo 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?
- watwut 9y agoYou can interweave everything into one long function full of ifs and switches. E.g. procesurally. Not saying it is better.