Question: After reading [Should package names be singular or plural?](https://softwareengineering.stackexchange.com/q/75919/7167) it occurred to me that I've never seen a proper debate covering one of my pet peeves: naming implementations of interfaces. 

Let's assume that you have a interface `Order` that is intended to be implemented in a variety of ways but there is only the initial implementation when the project is first created. Do you go for `DefaultOrder` or `OrderImpl` or some other variant to avoid the false dichotomy? And what do you do when more implementations come along?

**And most important... why?**

Answer: 
I decide the naming by the use case of the interface.

If the interface is used for **decoupling**, then I choose `Impl` for implementations.

If the purpose of the interface is **behavioral abstraction**, then the implementations are named according to what they are concretely doing. I often append the interface name to that. So if the interface is called `Validator`, I use `FooValidator`.

I find that `Default` is a very bad choice. First it pollutes code completion features, because the names always start with it. The other thing is that a default is subject to change over time. So what first might be a default can some time after be a deprecated feature. So either you always start renaming your classes as soon as defaults change or you live with misleading names.
Try to figure out what is more concrete or specific about the class than the interface and incorporate that into the name. 

Say you have an interface for persisting data, FooDao. Persistence could be to a flat file, an XML document, a spreadsheet, a relational database, a non-relational database, etc. If the class is persisting data to any SQL database, try FooSql implements FooDao.

If you have code specific to a relational database vendor, try FooMssql, FooOracle, or FooDb2. Or, maybe FooDaoMssql or FooDaoPostgre would suit your purposes better.

The point is, don't just add letters that only serve the purpose of creating a unique identifier; try to give the name something more meaningful. That has two good effects. It still communicates more meaning to the next developer, even if you have only one implementing class. Even if you start with only one implementing class, if you ever find yourself needing another implementation, you won't find yourself with names like ..Impl and ..Impl2, or ..Impl and ..Mongo.