Naming Your Adapter When Using the Adapter Pattern
At some point in your project you may need to use a third party API. One common approach for using third party APIs is to use the Adapter Pattern. The API that you use may be very specific to a particular technology.
When you do create these adapter classes that utilize that API you should avoid names for your adapter that relate to the particular technology.
For example, let's say that you have an API for the Sony Toughpad barcode scanner. You wouldn't want your adapter classes to be named SonyToughpadBarcodeScannerAdapter. You should avoid naming your adapter like this in favor of something more generic like BarcodeScannerAdapter.
This is because in the future you may need to adapt your adapter to a different API such as the Intermec Handheld Device barcode scanner. The name for you adapter will be adaptable to this API but the name will be misleading. At this point you have the choice of renaming your adpter to the more generic name. However, renaming comes with a cost.
Renaming files in version control systems means that you lose the history of those files. That is because in some version control systems the renaming of a files appears as two separate operations; delete (old file name), create (new file). Renaming files becomes problematic in version control systems, specially when you have branches for different versions of the applicaiton.
Things will be much easier if you simply avoid naming your proprietary classes to something relating to the underlying technology.
This concept applies to the adapter as well as any associated classes upstream.
The same thing would apply if you created an internal API for a reporting system or file transfer system.
So please avoid even hinting at the underlying technology brand when naming your adapters. Your maintenance programmers will thank you.