Exposing common values from a custom structure/type

Question

One of my projects has a value type/struct that represents a custom identifier string for a video format. In this case, it's going to contain a content type string, but that can vary.

I've used a struct so it can be strongly type when it's passed around, and perform some sanity checks on the initial string value.

public struct VideoFormat {
    private string contentType;

    public VideoFormat(string contentType) {
        this.contentType = contentType;
    }

    public string ContentType {
        get { return this.contentType; }
    }

    public override string ToString() {
        return this.contentType;
    }

    // various static methods for implicit conversion to/from strings, and comparisons
}

As there are a few very common formats, I've exposed these as static read only fields with default values.

public static readonly VideoFormat Unknown = new VideoFormat(string.Empty);
public static readonly VideoFormat JPEG = new VideoFormat("image/jpeg");
public static readonly VideoFormat H264 = new VideoFormat("video/h264");

Is it better to expose the common values as static read only fields or as get only properties? what if I want to change them later? I see both methods used throughout the .Net framework, e.g. System.Drawing.Color uses static readonly properties while System.String has a static read only field for String.Empty, and System.Int32 has a const for MinValue.

(Mostly copied from this question but with a more specific and not directly related question.)

Possibly related: [C#: Static readonly vs const](http://stackoverflow.com/q/755685/588306), [How best to implement publicly accessible constants in C#](http://stackoverflow.com/q/2889139/588306) — Deanna, Mar 19 '13 at 00:06

lahsrah · Accepted Answer · 2013-03-18T23:56:37.197

2

Properties are a good idea unless you are declaring something that never changes.

With properties you can change the inside implementation without affecting programs consuming your library and handle changes / variations. Consuming programs wont break and wont require to be recompiled.

e.g. (I know this is a bad example but you get the idea..)

public static VideoFormat H264Format
{
   get{
         // This if statement can be added in the future without breaking other programs.
         if(SupportsNewerFormat)
             return VideoFormat.H265;

         return VideoFormat.H264;
    }
}

Also keep in mind that if you decided to change a field to a property in the future, consuming code breaks.

edited Mar 18 '13 at 23:56

answered Mar 18 '13 at 23:50

lahsrah

9,013
5
37
67

In this case, fields will work the same way as properties won't they? – Deanna Mar 19 '13 at 00:00
How will you put logic in a field and return different result based on that logic? – lahsrah Mar 19 '13 at 00:06
Sorry, I was referring more to the value itself, allowing you to change it. Both can be changed (at design time) and apply in any callers? – Deanna Mar 19 '13 at 00:09
Yes both can be changed - but you can't convert a field to a property in the future, without caller being recompiled. – lahsrah Mar 19 '13 at 00:15

Exposing common values from a custom structure/type

1 Answers1

Linked