|Sent on:||Tuesday, March 5, 2013 10:49 PM|
My answer is biased by my experience in OSGi and preference for the service-oriented style that OSGi encourages.Interfaces must be kept separate from implementations: at the very least in separate packages, and perhaps in separate modules. This is because interfaces -- which are APIs or contracts -- evolve at a very different rate from implementations. APIs can only be evolved in agreement with other consumers or providers of those APIs, so changing them is something you do very cautiously. On the other hand implementations change all the time, e.g. with every bugfix. Coupling them together forces you to frequently re-release APIs that haven't actually changed. Though if you have disciplined, granular versioning then this isn't necessarily a problem.
Implementation class names are irrelevant. They are private inside my module, nobody will ever see them, so who cares?
It's rare to come across a service interface where you cannot imagine alternative implementations existing. If there really is only one way to implement something, then what you have is a utility rather than a service, and in this case I would just make it a simple concrete class. Arguably you might want to take a copy of that class into each module that uses it, in order to avoid cross-module dependencies on implementation code.
For these reasons -- and additionally for aesthetic reasons that I acknowledge are purely aesthetic -- I think that your idea of nesting a default implementation inside the interface is an utter abomination.