EIMI being an explicit interface member implementation. So instead of:
public int SomeValue{get;}
you have
int SomeInterface.SomeValue {get;}
I'm currently considering using one as i'm using an internal interface (to decouple, yet restrict) and I don't want to make the methods on the implementing object to appear in its public API.
Is this a good use case?
Yep, that's a good use case. According to C# Language Specification on MSDN:
Explicit interface member implementations serve two primary purposes:
Because explicit interface member implementations are not accessible through class or struct instances, they allow interface implementations to be excluded from the public interface of a class or struct. This is particularly useful when a class or struct implements an internal interface that is of no interest to a consumer of that class or struct.
Explicit interface member implementations allow disambiguation of interface members with the same signature. Without explicit interface member implementations it would be impossible for a class or struct to have different implementations of interface members with the same signature and return type, as would it be impossible for a class or struct to have any implementation at all of interface members with the same signature but with different return types.
A very good example is in the .Net generic collections classes.
For example, List<T> implements 'IList' implicitly and IList (non generic interface) explicitly. That means when you use the class directly you'll only see the specialized methods and not the ones that work with Object.
Let's say you instantiate a List<Person>. If IList was implemented implicitly you'd have two add methods directly accessible on the class Add(Person item) and Add(Object item), which will break type safety provided by generics. Calling list.Add("Foo") will compile just fine as the Add(Object) overload will get chosen automatically, and type safety provided by generics is gone.