IWonderAboutInterfaceNames

InfoQ has just published Udi Dahan’s talk from QCon 2008 on “Intentions and Interfaces”. It’s good to see the message about focussing on Roles rather than Classes being pitched to a new audience. That’s what we were trying to talk about in our “Mock Roles, Not Objects” paper.

I wonder, however, about his style for naming roles:

interface IMakeCustomerPreferred {
  void MakePreferred();
}
interface IAddOrdersToCustomer {
  void AddOrder(Order order);
}

It took me a little while to figure it out, but to me the issue is that these interface names bind the role to the underlying implementation, or at least to a larger role. One of the things that Nat Pryce and I discuss in our book is that interfaces need refactoring too. If two interfaces are similar, perhaps there’s a common concept there and they should be collapsed—which brings us more pluggable code. This implies that roles, as described by interfaces, should aim to be context-independent. In this case, I might rename one of the interfaces to:

interface IOrderCollector {
  void AddOrder(Order order)
}

since there will be contexts in which I really don’t care that it happens to be a Customer. That said, I think Dahan has other motivations with this naming scheme, since he also uses it to control retrieval from the ORM, but there might be other ways to achieve that.