J'ai créé une ObjectParser
classe qui analyse les données en objets fortement typés en utilisant un IObjectParserDataSource
comme source de données (les données peuvent être un fichier Excel, un fichier texte, un tableau, une chaîne de requête, etc.).
Des exemples de mes implémentations de IObjectParserDataSource
sont:
TextFileObjectParserDataSource
ExcelFileObjectParserDataSource
Ces noms de classe me semblent très longs et compliqués.
Je pourrais les nommer:
TextFileDataSource
ExcelFileDataSource
Mais cela introduit un certain niveau d'ambiguïté et ils ne sont pas devenus aussi clairement liés IObjectParserDataSource
à première vue. Cela devient important car la définition de ces sources de données se fera dans le code client et je souhaite minimiser la confusion et l'incertitude potentielles.
Comment nommeriez-vous ces classes dans un tel scénario?
la source
ExcelFileOPDS
,TextFileOPDS
. Cela économise un peu sur la saisie et l'espace d'écran, mais il est opaque pour quelqu'un qui n'est pas familier avec le code.Réponses:
J'essaie généralement de contourner ce problème en collant tous les objets similaires dans un espace de noms et en simplifiant leurs noms (si je peux le faire).
Par exemple, aurait
Ou, si la collection d'objets travaillant avec / servicing
ObjectParser
devient suffisamment grande, je créerais une arborescence de dossiers ou un projet distinct dédié uniquement à ObjectParser:Dans un fichier donné, les instructions d'importation et le contexte de code indiquent généralement clairement qu'il
TextFileSource
s'agit de laObjectParser
source de données. S'il y a plusieurs classes de même nom dans le même morceau de code, vous pouvez vous référer àTextFileSource
son nom complet:Cela se produit généralement très rarement et cela ne me dérange pas de taper quelques mots supplémentaires.
la source