|Custom Attributes In C#|
|Written by Mike James|
|Tuesday, 23 June 2015|
Page 4 of 4
Consider for a moment the problem of assigning a format to the fields of a struct using a new attribute - Formattable.
Implementing a rough sketch of such a facility reveals quite a lot about the difficulties inherent in doing a “good job” using attributes. The idea is simple, the implementation quickly becomes complicated.
First we need a new attribute:
There is nothing new here but it is worth saying that it would be better to implement the format string as a get/set property.
This attribute can now be applied to any field in any struct or class. Notice that you can restrict its application to say a field in a struct rather than a class.
Now that we have an attribute we can apply it:
Here we have a simple struct with two int fields one of which, cost, will hold a currency value and hence is tagged with the Formattable attribute set to Money. Immediately we have a problem in that the user can enter any string they care to into the new attribute – not just the few we want to allow.
One way of restricting the input to an attribute is to define an enum. For example:
With this enum the attribute definition changes to:
and the struct becomes:
Now the user really can only enter values that you provide.
The next task is to create some machinery to process the attribute. In this case we can assume that some sort of method has to be provided that displays the struct, taking notice of the attributes.
We are going to write a display method that accepts a struct and formats each of its fields depending on the annotation.
The simplest way of providing this machinery is to introduce a static class – after all why should we need to create instances of this machinery?
The first problem is what to pass to the method that does the formatting?
In principle we could pass any struct or class to the method and there really isn’t a type-safe way of doing this without using generics and this would complicate the example.
However as long as we actually test the type passed to the method this should at least be runtime type-safe. If you want to restrict what can be passed to structs you can, using:
Unfortunately this also allows simple types such as int and long to be passed so you need to add another test.
The problem is that struct isn’t a type, it’s a keyword that creates a struct which inherits directly from ValueType as do all simple types. This means you can’t separate all structs from the rest of the ValueTypes. You can’t even simply test to see if what has been passed in has fields to determine if it is a struct because simple types like int also have fields!
Moving on to provide the mechanism for inspecting and processing the attributes, the first step is to get all the fields:
Next we step through the array and process each field in turn:
We need the array of Formattable attributes that have been applied and in this case we also need the value of the field:
Notice that we should also check that the type of the field is suitable for the formatting about to be applied but this has been omitted for simplicity.
Now we can use the Formattable attribute object to determine what format string to store in format:
Notice there can only be one Formattable object because of the:
Finally we can display the result and close the foreach loop, method and class:
Of course in a real application we wouldn't just display the resulting format it would be use in some way.
Now you can write:
The cost field, tagged as money format, will display with a currency symbol and the notacost field will display without. Unfortunately as it stands the display method also accepts simple types so:
displays the two fields associated with a boxed int. There seems to be no elegant way of stopping this from happening.
One solution would be to require the Formattable attribute to be applied to the entire struct before any of its fields are processed. That is, change the attribute to
add a constructor that takes no parameters and add a test that the passed-in parameter did indeed have a Formattable attribute before processing it.
The static method that implements the machinery would be better associated with the struct or, in general, the types to which it applies i.e. it should be a method of the type is is going to display the fields of. The extension method facility can be used to retrofit methods to classes that already exist. You can even add new methods to build in types such as int or string.
Unfortunately the problem is that structs inherit directly from ValueType makes it impossible to add an extension method to all structs and nothing else. You can easily add an extension method to a single named struct but why bother… you might as well just add the method to the struct directly. To add the display method to all value types you simple change its definition to:
That is, add the modifier “this” to the first parameter. Now you can call the display method using:
In other words, the display method has been added to every struct you create – powerful isn’t it!
Unfortunately it has actually been added to every value type so you can also write:
which is perhaps not what you intended. In this case it will display the two fields supported by a boxed int i.e. the maximum and minimum values.
Attributes are something that you probably won’t use everyday, but now that you know exactly how they work you can spot when the approach might be useful.
To be informed about new articles on I Programmer, install the I Programmer Toolbar, subscribe to the RSS feed, follow us on, Twitter, Facebook, Google+ or Linkedin, or sign up for our weekly newsletter.
or email your comment to: email@example.com
|Last Updated ( Tuesday, 23 June 2015 )|