Attributes and API usability

I’m in the middle of running an API study this week with an API that makes heavy use of attributes throughout. Basically, much of the functionality that the API supports is largely exposed through the use of attributes. The API requires that you decorate classes, member variables and properties with attributes to implement some functionality. If you want to customise that functionality, you set various optional parameters on the attributes. There is very little (almost nothing) that you need to do in actual imperative code.

We’re half way through the study and are starting to see a pattern in the way that participants respond to the use of attributes throughout the API (once the study is over, I’ll let you in on more of the details…).

I’m interested in hearing what others think of such a use of attributes in an API. What advantages and disadvantages do you think such an API would offer? And do the advantages outweigh the disadvantages or vice versa? In your opinion, is the heavy use of attributes throughout an API a good or a bad thing?

Comments (6)

  1. Andrey Skvortsov says:

    Attributes as concept is a good thing no doubt,declarative programming and AOP is always good thing but implementation can be improved by providing completely decoupled alternative among other things IMHO.

  2. Mike Dunn says:

    Preface: My only exposure to attributes has been ATL in VC 7.1 (I don’t write managed code at the moment).

    I feel very uneasy about putting huge chunks of functionality in attributes, mostly because they seem to be this magical black box. Just a couple of days ago, I was working with a friend over IM to get an attributed ATL sample working for him. We were stumped on why the .rgs file wasn’t being read. Because all the registration stuff was generated by attributes (the C code didn’t have DllRegisterServer() or UpdateRegistry()) I had no way at all to debug it. In regular ATL I could just set a breakpoint on DllRegisterServer() and step through it.

    I also find heavily-attributed code extremely hard to read. When there’s actual _code_ there, I can usually figure out what it’s meant to do just by a careful reading. When there are attributes sprinkled all over, I have to bounce back and forth between the code and the docs, figure out what magic the attributes do, and then remember it all.

  3. I was thinking about this just the other day. I think that generally, attributes in code are awesome. I believe that they can provide very important functionality in with very little maintenance effort and extremely easy implementation.

    However, I also believe that as more and more library/framework creators catch the Attribute fever, we’re going to have far too many of them decorating everything. I think it might be time to search out an alternative way to represent the attributes (if not representation, then manageability, but that implies that there might be yet another tool to manage attributes, giving us a less usable IDE for our more usale API).

    Anyway, I think we’ll start to see a problem as we get too many attributes in our code.