I believe that when naming classes and interfaces in a system, they should be named after their purpose - not their implementation. This is purely a stylistic choice, but I'm always interested to see who does what. I've seen both practices employed, and while neither is "better", I have my preference.

When I started programming, I used to name things "Abstractxxx" and "Ixxx" to indicate that they were abstract classes or interfaces. I quickly found this was both redundant and could lead to confusion. It's redundant because languages that support the features of abstraction and interfaces have keywords that describe them, and most can generate documentation that logically separates interfaces from classes. It can lead to confusion because if you decide to refactor an object (such as extracting an interface at a later time or making something abstract concrete), you not only have to change the implementation, but the name as well. People familiar with a codebase then have to relearn the new names due to the refactoring change.

Of course, modern IDEs handle refactoring very gracefully (and might even find all your name references in non-code resources such as config files), but that's not really the point. The point is: choose your implementation and your names separately. That way, you can refactor whenever you feel like it and the purpose of the object is captured in its name without any unnecessary hints in to the implementation.