Назви відповідних класів та інтерфейсів

Я створив ObjectParserклас, який аналізує дані на сильно набрані об'єкти, використовуючи IObjectParserDataSourceяк джерело даних (дані можуть бути файлом Excel, текстовим файлом, масивом, рядком запиту тощо).

Прикладами моїх реалізацій IObjectParserDataSourceє:

• TextFileObjectParserDataSource
• ExcelFileObjectParserDataSource

Ці назви класів мені здаються дуже довгими і перекрученими.

Я міг би їх назвати:

• TextFileDataSource
• ExcelFileDataSource

Але це вводить рівень неоднозначності, і вони не настільки чітко пов'язані з IObjectParserDataSourceпершим поглядом. Це стає важливим, оскільки визначення цих джерел даних буде відбуватися в коді клієнта, і я хочу мінімізувати потенційну плутанину та невизначеність.

Як би ви назвали ці класи за таким сценарієм?

Я, як правило, намагаюся обійти цю проблему, вставляючи всі подібні об'єкти в один простір імен і спрощуючи їх імена (якщо я можу це зробити).

Наприклад, мав би

простір імен ObjectParserDataSources
|
| -> клас TextFileSource
| -> клас ExcelFileSource

Або якщо колекція об'єктів, що працюють з / обслуговуються, ObjectParserстане достатньо великою, я б створив окреме дерево папок або проект, присвячений саме ObjectParser:

namespace ObjectParser
|
|-> class ObjectParser
|-> interface IObjectParserDataSource
|
|-> namespace DataSources
|   |
|   |-> class TextFileSource
|   |-> class ExcelFileSource
|
|-> other stuff...

У будь-якому даному файлі висловлювання імпорту та контекст коду зазвичай дають зрозуміти, що TextFileSourceце ObjectParserджерело даних. Якщо в одному і тому ж фрагменті коду є кілька подібних іменів, ви можете посилатися на TextFileSourceйого повне ім'я:

var parserSource = new ObjectParser.DataSources.TextFileSource(/*...*/);

Зазвичай це трапляється дуже рідко, і я не проти вводити зайві кілька слів.