I have created an ObjectParser class which parses data into strongly typed objects using an IObjectParserDataSource as the data source (the data could be an Excel file, text file, array, query string, etc).
Examples of my implementations of IObjectParserDataSource are:
TextFileObjectParserDataSourceExcelFileObjectParserDataSource
These class names feel really long and convoluted to me.
I could name them:
TextFileDataSourceExcelFileDataSource
But this introduces a level of ambiguity and they don’t became as clearly related to IObjectParserDataSource at first glance. This becomes important because defining these data sources will happen in client code and I wish to minimize potential confusion and uncertainty.
How would you name these classes in such a scenario?
2
I generally try to get around this problem by sticking all similar objects into one namespace and simplifying their names (if I can do it).
For example, would have
namespace ObjectParserDataSources | |-> class TextFileSource |-> class ExcelFileSource
Or, if the collection of objects working with/servicing ObjectParser becomes large enough, I’d make a separate folder tree or project devoted just to ObjectParser:
namespace ObjectParser
|
|-> class ObjectParser
|-> interface IObjectParserDataSource
|
|-> namespace DataSources
| |
| |-> class TextFileSource
| |-> class ExcelFileSource
|
|-> other stuff...
Within any given file, the import statements and the code context would usually make it pretty clear that TextFileSource is the ObjectParser data source. If there are multiple similarly named classes in the same piece of code, you can refer to TextFileSource by its full name:
var parserSource = new ObjectParser.DataSources.TextFileSource(/*...*/);
It usually occurs very rarely and I don’t mind typing out extra few words.
2