Nazewnictwo powiązanych klas i interfejsów

Stworzyłem ObjectParserklasę, która analizuje dane w silnie typowane obiekty, używając IObjectParserDataSourcejako źródła danych (dane mogą być plikiem Excel, plikiem tekstowym, tablicą, ciągiem zapytania itp.).

Przykłady moich wdrożeń IObjectParserDataSourceto:

• TextFileObjectParserDataSource
• ExcelFileObjectParserDataSource

Te nazwy klas są dla mnie naprawdę długie i skomplikowane.

Mógłbym je wymienić:

• TextFileDataSource
• ExcelFileDataSource

Wprowadza to jednak pewien poziom niejednoznaczności i IObjectParserDataSourcena pierwszy rzut oka nie są one tak wyraźnie związane . Staje się to ważne, ponieważ zdefiniowanie tych źródeł danych nastąpi w kodzie klienta i chcę zminimalizować potencjalne zamieszanie i niepewność.

Jak nazwałbyś te klasy w takim scenariuszu?

Generalnie staram się obejść ten problem, umieszczając wszystkie podobne obiekty w jednej przestrzeni nazw i upraszczając ich nazwy (jeśli mogę to zrobić).

Na przykład miałby

przestrzeń nazw ObjectParserDataSources
|
| -> klasa TextFileSource
| -> klasa ExcelFileSource

Lub, jeśli kolekcja obiektów współpracujących z / servicing stanie ObjectParsersię wystarczająco duża, stworzę osobne drzewo folderów lub projekt poświęcony tylko ObjectParser:

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

W obrębie każdego pliku instrukcje importu i kontekst kodu zwykle jasno wskazują, że TextFileSourcejest to ObjectParserźródło danych. Jeśli w tym samym fragmencie kodu znajduje się wiele klas o podobnych nazwach, możesz się do nich odwołać po TextFileSourcepełnej nazwie:

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

Zwykle zdarza się to bardzo rzadko i nie mam nic przeciwko wpisywaniu kilku dodatkowych słów.