Processing multiple type of messages in multiple ways

Question

In a chat application there may be multiple types of incoming messages to be handled. For example, I have messages of these types: text, link, image, and video. Text and link are handled the same way, but image and video require the file to be downloaded from different server.

Also each message may need to be deleted. Deleting each message may be different as well, for example text and link messages just need to be deleted from a database but image and video may require the associated file to be deleted. There may be more such operations on messages that are supported on some type of message -- for example retry download in case of image and video.

I have thought of using double dispatch with visitor pattern but it does not fit properly. I need something like triple dispatch but I am not sure which design is better.

In the future, there may be more types of messages that may require different type of processing. What type of design will ensure adding a message type is least intrusive to infrastructure code? Preferably without adding items to "if" statements or "switch case" blocks.

Answer 1

Oh boy, there a lot going on here.

First of all, neither double dispatch nor triple dispatch are going to help you with this.

You're running into all the same problems a web browser runs into. You could solve these problems the same way. Text, Link, image, and video are all encoded a text language. That language is decoded to decide how to present it. This requires the ability to parse the language. If remote files are mentioned they are downloaded and cached. No need to delete so long as they can be overwritten freely.

Certainly you don't have to do it this way. Image and video data streams could be sent directly. Each message could have a field announcing what type it is. If's could be avoided by using that field's value in a hash or jump table to the procedure the message needs. Hope no one sends me a value that jumps me to the format hard drive procedure.

But no matter how you do it, something, somewhere, has to decide how to present the message you got. Keep in mind, switch statements are only evil when somewhere in your code base there are two of them switching on the same thing.

Answer 2

In the future, there may be more types of messages that may require different type of processing. What type of design will ensure adding a message type is least intrusive to infrastructure code? Preferably without adding items to "if" statements or "switch case" blocks.

Why not using CQRS, with a separate Command and Events for each type of message. So for text messages you would have SendTextMessage command with the coresponding TextMessageSent event; likewise, for images you would have SendImageMessage command with the coresponding ImageMessageSent. This architecture respects the SOLID principles, especially the Open close principle: for every new message type you just add new classes, you don't need to touch the existing code.

Also each message may need to be deleted. Deleting each message may be different as well, for example text and link messages just need to be deleted from a database but image and video may require the associated file to be deleted. There may be more such operations on messages that are supported on some type of message -- for example retry download in case of image and video.

For this you have some sagas/process managers that listen to the relevant events like VideoMessageDeleted that call some Infrastructure code that deletes the corresponding file from the storage.