One Interesting Use of Explicitly Implemented Interfaces

When you see a discussion of explicit interfaces, it is usually about resolving clashes in their signatures (see Explicit Interface Implementation Tutorial).

To rehash, you’d implement an interface explicitly to

• simulate variance (change parameters or return type in “overridden” methods);
• hide a member and add an equivalent member with a better name;
• force the client to call members only through the interface.

However, here’s another interesting use case very briefly mentioned in Framework Design Guidelines. An explicit interface comes in handy when it “includes mainly members supporting framework infrastructure, such as data binding or serialization.” A good example is an interface whose members are almost never accessed directly.

This got me thinking. Recently, we had a discussion at work whether our domain classes should be aware of their caching environment. Should a domain class implement a (hypothetical) ICacheable?

In the Domain Driven Design canon, you don’t mix persistence to the domain and thus keep it persistence-ignorant as much as possible. Caching is infrastructure, however, so it seems we can implement ICacheable explicitly as a necessary evil and still feel good about it, eh? I don’t know yet. I’m curious how this is going to shape.

I'd ask myself why I'm opposed to implementing the interface in the first place, and why your cache infrastructure is designed to force clients to violate it. One assumption or the other has to be faulty, so are your design principles faulty, or does your caching infrastructure have a design problem?

That's what I ask myself too. Caching is tricky, and in this particular case we're trying to figure out where the caching "concern" truly belongs.

I see caching as a separate concern. It might make sense to instead use some kind of surrogate approach where one class is responsible for providing caching logic for another. For example, you might have a Customer class and a CustomerCacheSurrogate class. The latter might be associated with the former via an attribute, or via manual registration with the caching service. Just thinking out loud here...

Whenever I use explicit interface implementation, it's because the interface must be implemented by the type but that interface is used solely by some plumbing somewhere (eg. .NET's ISerializable, CAB's IBuilderAware) and not by typical clients of the type.