4 ms·
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 func
by kuschku 9y ago
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?
- watwut 9y agoYou can interweave everything into one long function full of ifs and switches. E.g. procesurally. Not saying it is better.
- _pmf_ 9y ago> 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.
- jononor 9y agoHave 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.