用于分析的可扩展类型安全枚举类？

Question

I'm completely stuck with this for about 2 days now and it seems I simply can't get my head around the problem I'm facing.

Currently, I'm writing an SDP parsing library that should also be usable for creating correct SDP messages according to it's specification ( http://tools.ietf.org/html/rfc4566 ). But the specification is sometimes very open or unclear, so I try to implement a necessary amount of flexibility while still being as close to the RFC as possible.

Example Problem

A SDP message can contain media information (" m " field) where as this information has the following pattern:

m=<media> <port> <proto> <fmt> ...

And example message could look like this:

m=video 49170/2 RTP/AVP 31

Take a look at the proto flag, which stands for Media Transport Protocol . According to the specification, this field can have the following values:

• RTP/AVP
• RTP/SAVP
• UDP

This is a list of values, so it's obviously appropriate to take an enumeration.

public enum MediaTransportProtocolType {
    RTP/AVP
    RTP/SAVP
    UDP
}

Ooops! But this doesn't work because of the "/" char. So, how am I able to use this for parsing? I extended the Enumeration fields with the DescriptionAttribute

public enum MediaTransportProtocolType {
    [Description("RTP/AVP")
    RTP_AVP
    [Description("RTP/SAVP")
    RTP_SAVP
    [Description("UDP")
    UDP
}

Now I can simply look up the appropriate media transport protocol type by it's description. But now, the RFC specification goes on:

This memo registers three values [...] If other RTP profiles are 
defined in the future [...]

So it's possible that a future network device can send me an media transport protocol that I'm not aware of. The whole enumeration thing doesn't work here anymore as System.Enum is not extendable due to various reason.

Solution

On my way looking for a solution I met the Type Safe Enumeration Pattern (AKA StringEnum ) as described in here: how can i use switch statement on type-safe enum pattern . This answer even describes a solution to make them switchable, even if it's an ugly solution IMHO.

But again, this does only work for a defined range. I extended the Type Safe Enumeration class with a dictionary to store instances that I can look up while parsing, but also add new ones if I don't now them.

But what about all the other fields? And what about casting?

This answer here describes an approach with a base class and casting through explicit operators: Casting string to type-safe-enum using user-defined conversion

I tried it out, but it's not working the way I'd like it to be. (Invalid casting exceptions, dirty two casts pattern, not extendable).

How does one parse SDP information correctly and easily while still providing a library that allows to create a correct SDP?

Answer 1

You can do something like this:

public sealed class MediaTransportProtocolType
{
    public static readonly MediaTransportProtocolType RtpAvp =
        new MediaTransportProtocolType("RTP/AVP");

    public static readonly MediaTransportProtocolType RtpSavp =
        new MediaTransportProtocolType("RTP/SAVP");

        public static readonly MediaTransportProtocolType Udp =
        new MediaTransportProtocolType("UDP");

    public static readonly ReadOnlyCollection<MediaTransportProtocolType>
        Values = new ReadOnlyCollection<MediaTransportProtocolType>(
            new MediaTransportProtocolType[] { RtpAvp, RtpSavp, Udp });

    private MediaTransportProtocolType(string name)
    {
        this.Name = name;
    }

    public string Name { get; private set; }

    public static MediaTransportProtocolType Parse(string value)
    {
        if (string.IsNullOrEmpty(value))
        {
            throw new ArgumentNullException("value");
        }

        var comparer = StringComparer.OrdinalIgnoreCase;

        if (comparer.Equals(value, RtpAvp.Name))
        {
            return RtpAvp;
        }
        else if (comparer.Equals(value, RtpSavp.Name))
        {
            return RtpSavp;
        }
        else if (comparer.Equals(value, Udp.Name))
        {
            return Udp;
        }
        else if (value.StartsWith("RTP/", StringComparison.OrdinalIgnoreCase))
        {
            // Normally we would throw an exception here, but  future
            // protocols are expected and we must be forward compatible.
            return new MediaTransportProtocolType(name);
        }

        throw new FormatException(
            "The value is not in an expected format. Value: " + value);
    }
}

That allows you to use it as an enum like this:

var type = MediaTransportProtocolType.Udp;

And you can parse it:

var type = MediaTransportProtocolType.Parse(value);

And iterate over all known values:

foreach (var type in MediaTransportProtocolType.Values)
{
}

And parse returns a unknown/future protocol type as long as they start with "RTP/" (as defined by the specs).

Of course the question is, can your library handle 'unknown' protocols. If you can't, you shouldn't allow parsing them. You should throw an NotSupportedException and update the library when new protocols are added. Or if you want others to extend, you should allow others to define implementations that handle a specific protocol.