theburningmonk.com

One of the prob­lems with using F#’s Dis­crim­i­nated Unions is that they are not exten­si­ble, in that all your union cases must be spec­i­fied inside one Dis­crim­i­nated Union (abbre­vi­ated to DU from this point) type and you can’t inherit from an exist­ing DU type to add addi­tional union cases.

In most cases, hav­ing to spec­ify all your union cases inside one DU type makes per­fect sense and I’m sure there is a very good rea­son for the lan­guage design­ers to not allow inher­i­tance with DU types.

How­ever, some­times I do find myself wish­ing for some exten­si­bil­ity so that I can keep using DU types instead of hav­ing to revert back to a com­plex class hierarchy.

Sup­pose you have a mes­sag­ing appli­ca­tion, you can define the dif­fer­ent types of mes­sages your sys­tem under­stands as a DU:

How­ever, as the appli­ca­tion grows you might want to add more spe­cial­ized types of mes­sages, and you don’t want to add them to Mes­sageTypes to stop it from becom­ing bloated and to keep the spe­cial­ized mes­sage types closer to code that actu­ally under­stand them.

So what do you do in that case? Go back to using a class hier­ar­chy? Sure, that’s one approach.

Another approach to this prob­lem is to use marker inter­faces, so the above code becomes:

The fact that DU types can imple­ment inter­faces is often over­looked but you can make good use of it here to enable some exten­si­bil­ity to your DU types.

Notice how the func­tion f is changed from pat­tern match­ing the union cases to pat­tern match­ing against the type of the mes­sage (sim­i­lar to how you can use pat­tern match­ing in a try-with block) before pass­ing the mas­sage to the appro­pri­ate han­dler func­tion that under­stands that spe­cific type.

Well, thank you for read­ing and hope this post proves to be help­ful to you